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

[<[e-mail]>]

Hi Toerless,

the design of LE leading to the current draft allows for a domain
- to consume a DSCP which may pass a domain not supporting LE and this DSCP isn't bleached.
- to support LE internally without a requirement to negotiate LE support with other domains.

This works, if LE supports CC as default class traffic does. That would require the SHOULD related 
to CC in the current draft to be replaced by a MUST, if the LE traffic is sent across an 
interconnection link and there's no LE SLA in place.  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.

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

I don't favor solutions where a DSCP re-write is used for signaling. You expect an ECN like 
mechanism to be in place, where the receiver returns an information reporting a received DSCP to the 
sender. 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.

My general view is: don't link determined end to end transport behavior to DSCP values bearing no 
end to end significance.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Toerless Eckert
Gesendet: Freitag, 6. April 2018 18:04
An: [e-mail]
Cc: [e-mail]
Betreff: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

Some thought about CC and bleaching for LE (no multicast this time)

> LE traffic SHOULD be congestion controlled (i.e., use a congestion 
> controlled transport or implement a congestion control method 
> [RFC8085])

a) What would be the current summarized TSV IESG review requirement against a CC statement for BE ? I thought it was something like

  "MUST be CC controlled unless known to be operating across a controlled
  network, and even then it SHOULD use a circuit breaker [RFC8084]".

Whatever the right text is - IMHO it would be great if we knew that text, and then explained in the draft any difference in CC expectation for LE vs. these BE rules. I for once do not understand why a simple "SHOULD" would suffice. My starting point is that LE CC = BE CC, and then - see below.

b) 8085 has UDP in the title. It would be good if the CC text was amended to make it clear the requirement applies whatever the transport is. Not sure what the best magic text (or better reference) for non-UDP based transports is.

c) I couldn't figure out from rfc6297 if all the observed LE protocol
(profiles) would actually automatically receive less share of bandwidth if simply run together with "normal" TCP traffic in the same BE queue.

To me its somewhat logical that an LE transport protocol that knows it will get LE treatment could and should actually be somewhat more aggressive than a BE transport because it has to recover from more loss, or if ECN is used it needs more aggressive upspeeding to best utilize the likely a lot more fluctuating ressources in LE. 

Even if so far the researched LE CC mechanisms have not explored this "more aggressive" behavior, i think it would be great if we could define the right option for it, to make LE even more useful with future network profiles (see point f below). But of course the challenge then is how to make sure such more aggressive LE would never kill BE in the Internet:

d) The document only mentions what happens when LE traffic gets BE treatment in passing:

  [about SHOULD do LE CC]:
  "but is also essential if LE traffic is mapped to the default PHB
   in DS domains that do not support LE"

I think wrt. to CC requirements against LE traffic, we should make it front and center to define LE CC behavior in comparison to BE CC behavior - else we will get all type of unpredictable results when folks start to use various LE protocols:

I) LE CC must ensure that if operating across a congested hop that is treating LE as BE, LE CC MUST NOT give LE traffic more bandwidth share than the competing BE traffic, and it SHOULD give it less share.

So i hope thats the uncontentuous part. Here is the interesting part:

II) LE CC MAY be more aggressive than BE CC (give it more share than BE traffic if LE traffic is treated as BE) only if known to operate across a fully LE enabled path (every hop supporting LE). In this case, LE CC MUST fall back to I) when it can suspect that the path is not fully LE capable.

But how could LE CC ever meet the "MUST fall back" expectation ?

e) I don't think LE CC can ever figure out the "MUST fall back" except through bleaching (or other to be invented signaling).  But the "do not bleach" rule of the current text is really the most useful rule for the Internet to make introduction of LE into Internet nodes as attractive as possible.

II-bleach) LE CC MAY be more aggressive than BE CC (give it more share than BE flows) only if known to operate across a controlled network where the path is expected to support LE on every hop. Paths meant to support more aggressive LE CC SHOULD bleach LE to BE on hops that do not support LE. LE CC MUST fall back to be equal or less aggrssive than BE CC when receiving bleached packets (DSCP set to BE).

So, this allows more aggressive than BE, but only for controlled networks.

f) Here is an example where i think more aggressive LE will be quite
valuable: IMHO, we may see a lot more non-TCP friendly traffic in their own queues, the more inelastic and short-term bursty services start to appear on SP networks. I would think especially in 5G/6G and metro networks, DetNet style traffic or really high bitrate/bursty AR/VR traffic will want to have a lot of low-latency trafic that is little, or not congestion controlled. And this can nicely be stuffed into separate priority queues and get what it wants (Benefit of having a large SP network).

So this is then a very ragged base load on the links. Then i add BE traffic, which CCs to mid to longer term available remaining bandwidth. That leaves a lot of shorter term ragged cliffs left over which can only be grabbed by more aggressive CC than BE willing & able to deal with this highly variable leftover bandwidth.

Aka: Taking bandwidth unused in a pure BE network is simple and works with less aggressive CC than BE-CC. Scavenging remaining bits from more interesting "multi-service" network loads is the real scavenging job requiring more aggressiveness.

Cheers
    Toerless