Re: [p2pi] TANA proposed charter -- packet marking question

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 24 October 2008 20:24 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 445F328C14F; Fri, 24 Oct 2008 13:24:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B40B28C131; Fri, 24 Oct 2008 13:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.817
X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MeEJ2fu+JYFz; Fri, 24 Oct 2008 13:24:29 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 4C14A28C13F; Fri, 24 Oct 2008 13:24:29 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id m9OKPTMP028866; Fri, 24 Oct 2008 13:25:30 -0700 (PDT)
Message-Id: <>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Stanislav Shalunov <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 24 Oct 2008 13:25:29 -0700
References: <> <> <> <20081024145218.GB88592@verdi> <> <>
X-Mailer: Apple Mail (2.929.2)
Cc:,, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [p2pi] TANA proposed charter -- packet marking question
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

On Oct 24, 2008, at 11:33 AM, Stanislav Shalunov wrote:

> On Oct 24, 2008, at 8:09 AM, Nicholas Weaver wrote:
>> NAT box or DSL modem (not sure which at this moment) has a 3 second  
>> packet buffer, and simple FIFO behavior.
> I'm willing to bet it's the DSL modem and that the actual buffer  
> size is a binary-round number, likely 64kB.

Confirmed by subsequest testing.

Although I think its 128 kB:  Sustained transfer rate is >40 kB/s, and  
latency is ~3S.

And my ISP has its own problem, the downlink is also overbuffered, but  
more like 1s.

> By the way, buffer provisioning for slow links is a problem that's  
> harder than the "one RTT worth divided by whatnot" rule makes it out  
> to be.  If anyone who makes DSL/cable modems is listening, please  
> don't just cut the buffer -- it may well do more harm than good.

You're right.  Point taken.

But some of these are just SO far off what they should be that they  
really do need to be cut, badly.

There is probably a good argument for 300ms, 100ms, and perhaps even  
30ms (under the "better underbuffered then overbuffered" argument),  
and tradeoffs between maintaining peak TCP performance and maintaining  
interactivity if there isn't active queue management.  This needs to  
be hashed out (TANA isn't the place, but it does need to be someplace.)

And there may be arguments that you want something different on DSL  
(which is point to point) or DOCSIS (mediated shared access).   Or  
even something adaptive.

But 1s and 3s are just so far out there for typical residential  
networks and do represent a big issue, as such buffers mean that a  
single full-rate TCP flow makes the network completely unusable for  
interactive tasks.

What is the right IETF working group that should address this issue,  
to provide better guidance to equipment makers?

p2pi mailing list