Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

[<[e-mail]>]

Hi Toerless

thanks, my comments are marked [RG].

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Toerless Eckert [mailto:[e-mail]] 
Gesendet: Dienstag, 10. April 2018 09:44
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]
Betreff: Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

On Mon, Apr 09, 2018 at 07:13:15AM +0000, [e-mail] wrote:
> I'd be rather unhappy to receive "aggressive" 
> streaming traffic from a peer and be told that it is behaving 
> correctly, cause it's marked LE and my domain could support an LE class to deal with it.

Right. which is why in the first place, it would be good to distinguish between "BE compatible" and "not BE compatible" LE CC. 

[RG] This may be a good idea.

> There's another option beside bleaching unknown DSCPs at domain 
> boundaries, which is to drop or bandwidth limit traffic. Both options 
> may be more viable, if the traffic which is limited or dropped is more 
> aggressive than the kind of traffic which is covered by some SLA (like default class traffic assuming CC coupled with a best effort transport).

Right.

Is there any explicit policy option that could be recommended ?
Traditionally the solutions are trying to throttle traffic on a per-flow basis, but thats quite expensive. Not sure if any of the neweer AQM schemes could result in the desired effect.

[RG] AQM would have to be deployed in the complete domain to 
limit the CC-unfriendly traffic at the point of congestion. That 
means to support LE within the domain. If a provider isn't interested 
in that, the decision might be to limit incoming traffic.

> If you require an ECN like behavior, why not using ECN? In your case: 
> combined with the LE DSCP. That may allow to signal "no support" for 
> aggressive load expansion by ECN, rather than by DSCP rewrite.

Nice idea.

I guess this gets us to a point where we would need more actual testing/simulation to figure out if LE CC would really need to be BE incompatible to be able to scavenge all the bits that normal BE and BE compatible LE traffic could not utilize.

Aka: I would like to use this proposal of yours if i knew whether it would work or not. But i don't. And if no other prior work gives better insight, its probbly best not to make any normative statements about how to deal with "non BE compatible LE CC", but at best rather have informational text disussing that option as open and to be explored.

[RG] I favor "open and to be explored". For the time being, I have no experience in operating LE (and co-existence with BE).