Von Grant Fugal
von at fugal.net
Wed Dec 3 10:38:20 MST 2008
<quote name="Jason Wright" date="Mon, 1 Dec 2008 at 12:21 -0700">
> 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)
Precisely, torrents use a buttload of connections, not only is this bad
as you describe here with more than fair shair, it's also bad because it
bears immense overhead. Connection oriented _is_ the problem, hence why
switching to UDP might not be a bad idea after all.
> , but all-in-all it's the best we've
Just because something is the best we've got doesn't mean we should
never try anything new!
> 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.
You don't know that uTorrent is going to just simply use UDP to bypass
congestion control and blast away, in fact it is stated that they have
congestion control mechanisms in the works, or completed, not sure. The
goal here isn't to slurp up bandwidth, it's to get away from TCP
because, frankly, TCP is ill suited to torrenting. In fact, wouldn't it
be nice if they used something a little more like TCP Vegas, where
congestion is detected based on RTT instead of waiting till packet loss.
We can't get this better behaviour in TCP without a flag day, but if
uTorrent adopts something like it, it will graciously step down and
allow greater portions to the more greedy TCP.
> 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.
What if what if what if. If people are going to play nice on the
internet then we can have our current internet. If people aren't going
to play nice then we need a new, enforceable internet. It's really that
simple. uTorrent can do whatever it pleases, because there's nothing to
> >> 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.
Until then, the sky is falling.
> >> 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.
I'd like to echo the other comment:
Was there ever a case for net neutrality?
Well, it's a noble thought, and not without it's merits, but the
downsides severely outweigh the benefits, IMO. And if uTorrent decides
to be nasty, and lots of people decide to use it that nasty way, that's
just one example of many many possible downsides.
Government is a disease that masquerades as its own cure
-- Robert Lefevre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20081203/aadbe08e/attachment.bin
More information about the PLUG