[IP] Comments on LARIAT and Comcast not same problem

[David Farber <dave@farber.net>]

________________________________________
From: Dan Lynch [dan@lynch.com]
Sent: Monday, February 18, 2008 8:16 PM
To: David Farber; 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> wrote:

>
> ________________________________________
> From: David P. Reed [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]
>> Sent: Sunday, February 17, 2008 2:36 PM
>> To: David Farber; ip
>> Cc: 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
>>
>>
>> -------------------------------------------
>>
>>
>
> -------------------------------------------



Tel. 707-967-0203   Cell  650-776-7313
My assistant is Dori Kirk   Tel. 707-255-7094  dori@lynch.com




-------------------------------------------