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

John Leslie <john@jlc.net> Fri, 24 October 2008 16:11 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFA43A6AE9; Fri, 24 Oct 2008 09:11:52 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2721D28C1D9; Fri, 24 Oct 2008 09:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DflQngOPp0y; Fri, 24 Oct 2008 09:11:50 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 2CF743A69B9; Fri, 24 Oct 2008 09:11:50 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id E2AFB33C41; Fri, 24 Oct 2008 12:12:46 -0400 (EDT)
Date: Fri, 24 Oct 2008 12:12:46 -0400
From: John Leslie <john@jlc.net>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Message-ID: <20081024161246.GD88592@verdi>
References: <36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com> <AEDCAF87EEC94F49BA92EBDD49854CC707E291F2@E03MVZ1-UKDY.domain1.systemhost.net> <3615ACF9-49D1-4D66-A1AE-345684CF1A9D@shlang.com> <20081024145218.GB88592@verdi> <C19968F8-28BF-4BE1-B582-798DC45849CA@icsi.berkeley.edu>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <C19968F8-28BF-4BE1-B582-798DC45849CA@icsi.berkeley.edu>
User-Agent: Mutt/1.4.1i
Cc: tana@ietf.org, p2pi@ietf.org
Subject: Re: [p2pi] TANA proposed charter -- packet marking question
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> wrote:
> 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.

   I agree, there are some horrible examples.

> 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.

   Fortunately, the Linksys _could_ be easily programmed to fix that --
and if the problem becomes obvious enough to enough buyers, the
competition will fix it...

> 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.

   Agreed. (And there are a number of different flavors of congestion
in the 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.

   Agreed, we can't rely on it.

   But we shouldn't rule out optimizing the happy case where there's
full support for one or more of these through to the actual bandwidth
bottleneck. It's not actually all that hard to get there, for clueful
users...

--
John Leslie <john@jlc.net>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi