On 10/24/07, Levi Pearson <[EMAIL PROTECTED]> wrote: > "Andrew Jorgensen" <[EMAIL PROTECTED]> writes: > > > As long as you don't do a significantly worse job than the authors > > of TCP and you're not trying to implement all of the features of TCP > > you will not have "slower downloads" than you would with TCP. > > Assuming that you can do as good a job as the authors of TCP is > questionable. It's a complex protocol, and is that way for a reason. > It has developed to where it is today by responding to real-world > challenges, and it has proved to be effective at meeting them. Have > you seen the book 'TCP/IP Illustrated'? Not a small tome.
Doesn't that book contain chapters on all the major protocols at the time it was written? FTP alone could take up a big chunk of that. I've read the RFCs for several protocols (including TCP). My assertion is that if you don't need all that complexity you can save a lot by not using it. > One of the key features of TCP is congestion control. As a network > scales, the performance characteristics of a protocol change > significantly from when they operate in a vacuum. As Hans mentioned > earlier, the early internet was severely hampered by congestion; as a > result, TCP congestion control was introduced and overall throughput > increased dramatically. > > Considering that Comcast is doing this stuff as a result of > congestion, and that bandwidth usage is only likely to increase, do > you think moving one of the primary uses of bandwidth to a protocol > that doesn't do congestion control is a good idea? I certainly never said it was a good idea. In fact I was very clear about not endorsing a new protocol. Yours and Hans' point regarding congestion is valid. Oh gosh, suddenly it has become clear to be that the Internet is not a truck, it's a series of tubes! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
