Subject: Re: [tsv-area] [p2pi] DSCP or not

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 11:11:55 -0700

This is a TANA discussion and should for now be on tsv-area.

The real challenge in deploying scavenger is not even the core, which  
is infrequently congested, but the very edge, which gets congested on  
every upload.  Many more devices (cable and DSL modems), most of them  
hard to manage en masse.

A practical solution, therefore, must be end-to-end.  Whether to add a  
DSCP marking to the traffic is an orthogonal question, and the answer  
is likely positive, if we can find a suitable codepoint.  I expect we  
can, with 001000 being the most obvious candidate.

This will be particularly useful if networks would exclude scavenger- 
marked traffic from quotas, etc.

Since we can't rely on a network that does not support scavenger to do  
anything with scavenger traffic (including resetting the DSCP), having  
a negotiation that switches between algorithms is challenging.   
Consider that most head ends of congested bottlenecks are not even IP  
devices.

-- Stas

On Jul 31, 2008, at 7:37 AM, Toerless Eckert wrote:

>
> Seems to me as if the best long term solution would be to utilize a  
> scavenger
> DSCP class in the network.  For such a class i think the existing
> flow control mechanisms as eg: in TCP may not be suited best to  
> exhaust
> the available bandwidth - as it likely fluctuates more frequently and
> short term than in best effort. SSo some form of agressive  
> transmission with
> effecient retransmission (and maybe FEC) is probably best when using
> such a scavenger clas.
>
> Practically speaking, it will be a long time for most core networks
> to support such a clss, specifically because of the limited number of
> exp bits in MPLS, inertia, technical problems, and so on. So now
> we need the algorithm to handle scavenger traffic in the best effort  
> class,
> that very carefully tries not to cause any congestion and in face of
> congestion throttles itself back to zero or close to it.
>
> If we could bring together those two algorithms together, and the
> algorithm for a connection would be selected based on whether or not  
> the ntework
> resets the scavenger DSCP class to best effort (because there is no  
> scavenger class
> configured) ... then i think this would be a good short and long  
> term solution.
>
> Cheers
>    Toerless
> _______________________________________________
> p2pi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2pi

--
Stanislav Shalunov