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

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