jasonwright365 at gmail.com
Mon Dec 1 12:21:06 MST 2008
On Mon, Dec 1, 2008 at 11:36 AM, Michael Torrie <torriem at gmail.com> wrote:
> Andrew McNabb wrote:
>> On Mon, Dec 01, 2008 at 10:58:24AM -0700, Michael Torrie wrote:
>>> Bittorrent's new udp protocol is an attempt to address the problems
>>> and make bittorrent more palatable to business users and isps because
>>> it does have it's own built-in controls now to make it coexist better
>>> with other forms of traffic that were previously harmed. I don't
>>> think they've done this without thinking about the long-term
>>> consequences. Nor is this an attempt to somehow beat ISP throttling.
I'm not sure I agree with this. TCP does throttling already, plus it
has an awful lot of connection-oriented control already. There are
some problems with it. (i.e. if you have multiple streams, you use
more than your fair share of the bandwidth, tcp global
synchronization, + a few others), but all-in-all it's the best we've
Plus, there is a lot of measures to ensure that window size is
appropriate. Some routers/firewalls/etc use TCP information.
1) Redesigning a connection-oriented protocol to work on top of UDP
seems monumental and would extremely difficult to do efficiently.
2) As far as routers and firewalls are concerned, when using UDP each
packet is independent and routers cannot drop packets based on TCP
3) I haven't heard one piece of legitimate evidence that this will be
better for the Internet besides uTorrent says so (I don't trust the
good word of a bittorrent company)
4) Most of the people commenting who have some sort of computer
knowledge know that UDP is a connectionless protocol and TCP is a
connection-oriented protocol. There are a lot more to each protocol
(especially TCP) Read the RFCs (and understand them) --especially ones
discussing TCP congestion controls. Read papers discussing problems.
Trust experts, and if you can't do that, become an expert.
5)Richard Bennett is a network architect and occasional activist in
Silicon Valley. He wrote the first standard for Ethernet over
twisted-pair wiring and contributed to the standards for Wi-Fi and the
Ultra-Wideband wireless networks.
Richard Bennett is right on the money. By disguising traffic using
UDP, the Internet is going to bomb. The best thing TCP does is let
everybody play fairly (as much as is possible) If utorrent implements
this, we will see caps on bandwidth, because 5% of users will
consistently use 95+% of the bandwidth and kill routers.
Now if utorrent decides they will release the specifications of their
new connection-oriented protocol for public scrutiny (high level of
personal doubt) then we can have a more informed discussion.
>> Interesting. So does this mean that Bittorrent is implementing an
>> alternative form of congestion control? As you point out, that would
>> really change the story.
If Bittorrent releases their congestion control ideas, then we can
talk. Until then, I've never thought of Bittorrent and congestion
control are working against each other.
>> I'm still curious, though, about what would happen if we had net
>> neutrality laws and some application tried to beat ISP throttling with a
>> very aggressive protocol. I'm wondering how a staunch net neutralist
>> would view this hypothetical situation.
Net neutrality, unless you plan to violently kill the internet.
Oh, and for the curious...
# RFC 675 - Specification of Internet Transmission Control Program,
December 1974 Version
# RFC 793 - TCP v4
# RFC 1122 - includes some error corrections for TCP
# RFC 1323 - TCP-Extensions
# RFC 1379 - Extending TCP for Transactions -- Concepts
# RFC 1948 - Defending Against Sequence Number Attacks
# RFC 2018 - TCP Selective Acknowledgment Options
# RFC 2581 - TCP Congestion Control
# RFC 2988 - Computing TCP's Retransmission Timer
# RFC 4614 - A Roadmap for TCP Specification Documents
# RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
# RFC 3390 - TCP Increasing TCP's Initial WindowOriginal RFC3390]
# RFC 2309 - April 1998: Recommendations on Queue Management and
Congestion Avoidance in the Internet
More information about the PLUG