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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id F167028C12E; Fri, 24 Oct 2008 08:07:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9324C28C12E; Fri, 24 Oct 2008 08:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.759
X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LvQbn1Ctd3kP; Fri, 24 Oct 2008 08:07:52 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 3CD563A6881; Fri, 24 Oct 2008 08:07:52 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id m9OF9AEZ020053; Fri, 24 Oct 2008 08:09:11 -0700 (PDT)
Message-Id: <>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: John Leslie <>
In-Reply-To: <20081024145218.GB88592@verdi>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 24 Oct 2008 08:09:10 -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 7:52 AM, John Leslie wrote:
>   By the nature of a packet-forwarding internet, there will be delays
> due to queues filling. Thus marking packets as eligible for dropping
> as queues fill is a fundamental tool for controlling delay.
>   In the particular cases that are driving this work, a majority of
> end-systems involved will have uplink bandwidth configured to be less
> than downlink bandwidth. Thus, uplink queues may tend to fill first;
> and packet marking for the benefit of the first uplink router would
> have an obvious payback...

However, much of the problem arrises from the first uplink router, the  
one in the home, being horribly, HORRIBLY engineered.

A simple test:  A Linksys WRT64GL with the Linksys default firmware is  
my access router, connected to a generic DSL modem.

I have a sustained ping to a remote system at ICSI, 30ms away.

I start a full rate, SINGLE TCP flow to this remote system.  The ping  
time jumps up to 3 seconds!  Yes, the stupid NAT box or DSL modem (not  
sure which at this moment) has a 3 second packet buffer, and simple  
FIFO behavior.  Any full rate upload and I can kiss my connection  
goodbye.  Period.  End of story.  Have a nice day.

Remember, there are two problems that a scavenger class service must  
accommodate: the criminally overbuffered home access devices and  
common congestion in the ISP's uplink.

Packet marking may work great for the ISP's uplink, but I feel we must  
consider the access link devices to be stupid: Overbuffered, and with  
no support for any advanced queuing operation, ECN, DiffServe, or  
anything else, thus any scavenger class protocol can't rely on support  
for advanced traffic management features.

p2pi mailing list