Re: Comments on LARIAT and Comcast not same problem

[David Farber <dave () farber net>]

________________________________________
From: Richard Bennett [richard () bennett com]
Sent: Tuesday, February 19, 2008 5:51 AM
To: David Farber
Cc: ip
Subject: Re: [IP] Comments on  LARIAT and Comcast not same problem

It's naive to assert that Jacobsen's mechanisms have served us for 20 years since they've actually been revised at 
least twenty times and still fail to address the fundamental problem of per-user fairness. The most recent revisions 
address a perverse behavior when one or more links run WiFi, where packet loss is typically the result of a high 
intrinsic error rate rather than congestion. The WiFi variation ignores the first packet drop from the 
decrease/increase effect on window size. Jacoben's fundamental error is overloading packet loss with congestion 
signaling instead of adding an explicit congestion signal into the IP layer.

The problem that network operators have today is to prevent small numbers of users from using disproportionate 
bandwidth, which isn't really the same as protecting the Internet's interior links from congestion. This problem was 
unsolved by the TCP/IP architecture before and after Jacobsen's kludge.

RB

David Farber wrote:

________________________________________
From: Dan Lynch [dan () lynch com<mailto:dan () lynch com>]
Sent: Monday, February 18, 2008 8:16 PM
To: David Farber; dpreed () reed com<mailto:dpreed () reed com>
Subject: Re: [IP] Comments on  LARIAT and Comcast not same problem

Ah yes, Reed adroitly points out that the purpose of a file transfer is to
get the data from one place to another as quickly as possible.  About 20
years ago Van Jacobsen analyzed the behavior of the TCP protocol
implementations extant and came up with the congestion control mechanisms
that serve us to this day.  Hey, leaving a data link idle is wasteful.  Now
the trick of "fairly" allocating the link to competitors is what was
resolved long ago.  Networking is simple, but not easy.  (Or is it the other
way around?)

Dan


On 2/18/08 12:31 PM, "David Farber" <dave () farber net><mailto:dave () farber net> wrote:



________________________________________
From: David P. Reed [dpreed () reed com<mailto:dpreed () reed com>]
Sent: Monday, February 18, 2008 1:30 PM
To: David Farber
Cc: ip
Subject: Re: [IP] Re:     Comments on  LARIAT and Comcast not same problem

Would it be rude to point out that TCP "relentlessly attempts to consume
every shred of available bandwidth" along the path between source and
destination?

In fact, the AIMD (additive increase/multiplicative decrease) congestion
control mechanism used by TCP does *exactly* that.   In particular, it
consumes more and more bandwidth until it starts losing packets along
the way due to router buffer exhaustion.

So using TCP for anything, fetching a web page, uploading a file or
downloading a file is *just as bad* as using BitTorrent in terms of
consuming bandwidth if the concern is "relentless attempts".

BitTorrent uses TCP just like any other file transfer program, and it
responds to congestion just as any other file transfer does.

I would suggest that this discussion is on as "solid" ground as the
claims about "aluminum tubes" in the run-up to Iraq, where the technical
experts knew that the Cheney/Rumsfeld/Rice axis of deceit were engaged
in pure hype about the "only possible use" of such tubes being
separation centrifuges.

The use of "relentless" is a trigger for "hype alert" status.

David Farber wrote:


________________________________________
From: Brett Glass [brett () lariat net<mailto:brett () lariat net>]
Sent: Sunday, February 17, 2008 2:36 PM
To: David Farber; ip
Cc: tlauck () madriver com<mailto:tlauck () madriver com>
Subject: Re: [IP] Re:    Comments on  LARIAT and Comcast not same problem

At 07:14 PM 2/16/2008, Tony Lauck wrote:





It is a slight exaggeration to say that P2P relentlessly attempts to
consume every shred of available bandwidth. This is not the case with
properly set up bit torrent clients.



The default is for it to do so. And how many gamers, thirsting for
the latest World of Warcraft update, would change that default (if they
knew how)?




In my case, I have configured my bit torrent client so that it uploads
no more than 1.5x the volume of data that I choose to download, and it
does so using no more than 50% of my peak DSL upload bandwidth. There is
nothing relentless about this.



Alas, there is. Even if you throttle your BitTorrent client, your system
(and your ISP) will be beaten on relentlessly with requests for the
material. Day and night. Long after your own download is done. And unless
you "relent" by not doing P2P, you are still taking your ISP's bandwidth
for a third party. (See my comment to the FCC, mentioned earlier on this
list.)




If I download at high speed for an hour,
then my computer will upload at a reduced rate for perhaps ten times
that period of time. If the network is overloaded then it will download
at a lower rate for a longer period of time.



The entire point is that your software cares not whether any network
is "overloaded," and seeks to bypass all of the safeguards against
congestion which are part of the TCP/IP protocol suite. It is thus
abusive to the network.




Proper network management, in my book, means building and managing a
network so that cooperating users get good service, and so that non
cooperating users can get better service by becoming more cooperative.



We attempt to do that. One of the most effective P2P mitigation tactics
we've tried is to slow down the user's connection to compensate for the
excessive duty cycle of P2P applications, keeping the net load (in
gigabits per month) imposed on the network by the user down to a
reasonable level. It's the equivalent of, say, limiting the number of
plates that a customer at a buffet can fill. Under this regime, users who
honor their contracts and are not abusive find that their browsing and
other legitimate activities are faster, because they can burst to higher
traffic levels. But ones with a 100% duty cycle can't, and so find
activities that need a burst of speed -- e.g. browsing -- to be more
sluggish. The flaw in this scheme is that it still lets abusers take
bandwidth from us for the benefit of third parties, such as Blizzard
and Vuze, without compensation.




Some network operators seem to be better than others at achieving
effective cooperation. Perhaps this is due to superior technology, more
favorable business conditions, or superior management philosophy.

I hope that the successful networks are succeeding due to their
superior technology, because I have more faith in progress in the
technical dimension than in the management dimension -- not to mention
the political dimension, where progress seems to be retrograde more
often than not.



I believe that the form of behavior modification mentioned above is,
indeed, superior technology, as it uses a firm but gentle hand to
motivate users to do what they have agreed to do and not abuse the
network or use abusive technologies such as P2P. This, is of course,
one man's opinion, but it reflects the views of many in the industry.

--Brett Glass, LARIAT.NET


-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com




-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com





Tel. 707-967-0203   Cell  650-776-7313
My assistant is Dori Kirk   Tel. 707-255-7094  dori () lynch com<mailto:dori () lynch com>




-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com


-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com