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

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

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
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi