Re: [tsvwg] Signaling CE interpretation by a DSCP

[Roland Bless <[e-mail]>]

Hi Brian,

On 19.05.20 at 23:12 Brian E Carpenter wrote:
> I'm kind of baffled how we can discuss anything even vaguely resembling end to end signalling using DSCPs which are *by definition* domain-specific and mutable at domain boundaries. Even the phrase "standard DSCP" made me blink. No such thing exists except at the "RECOMMENDED" level.

I think Ruediger used the term standard DSCPs and probably meant
recommended DSCPs.
Sure, you are right that DSCPs are tied to the DS domain concept and
domains may remark at will. However, the WebRTC QoS approach
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos
essentially was based on using DSCP marking. Having at least the
possibility to get a recommended DSCP through unmodified end-to-end
would be useful in several situations.

Regards,
 Roland


> If we had allocated 5 bits for DSCPs and 3 bits for ECN, life would be different.
> 
> Regards
>    Brian Carpenter
> 
> On 20-May-20 08:39, Roland Bless wrote:
>> Hi Rodney,
>>
>> see below [RB].
>>
>> On 19.05.20 at 16:22 Rodney W. Grimes wrote:
>>> 	Clarification on how L4S is specified *today*. [RWG]
>>> Regards,
>>> Rod Grimes
>>>
>>>> Hi Ruediger,
>>>>
>>>> On 19.05.20 at 12:04 [e-mail] wrote:
>>>>> [RudiG]: Don't know whether that makes sense. If DSCP was not an input to the network, but rather an output ?
>>>>
>>>> In general, a DSCP can also be an "output": packets can be remarked
>>>> indicating a different PHB (see the AF PHB group for example: marking
>>>> partially happens according to queue management).
>>>>
>>>>> [RudiG]: Meaning: the router setting CE marks knows the method it uses to set them. I'd expect that router to be close to the terminal. A standard DSCP on the last mile may be accepted as a standard value and pass unbleached (unless it is consumed already for any other purpose). Thus the router could indicate by a DSCP, that it speaks "classic CE" or "L4S CE", whenever it is getting active on the ECN bits.
>>>>
>>>> The problem is that it may be then still unclear to the receiver
>>>> whether a CE that was set earlier on the path, or whether it
>>>> was set by the L4S router.
>>>> Currently, CE marked packets will also enter the
>>>> L4S low latency queue and in this case it would be better
>>>> to not set the DSCP (for experienced L4S handling) and let it
>>>> enter the classic queue instead.
>>>>
>>>>> [RudiG]: That's not well thought through, just an idea.
>>>>
>>>> My idea was that having a DSCP indicating L4S treatment one could
>>>> interpret ECT(1) as congestion signal of the L4S queue and CE still
>>>> as classic ECN congestion signal. CE marked packets would enter the
>>>> classic queue and DSCP L4S+ECT(1) would enter the L4S queue.
>>>> Currently, if ECT(1) is used as L4S classifier, that classification
>>>> possibility is gone after CE was set once. That would be avoided
>>>> if using a DSCP as classifier and ECT(1) as a different CE indication.
>>>> Furthermore, other reactions for ECT(1) could be used in conjunction
>>>> with a corresponding DSCP as you suggested.
>>>
>>>  [RWG] as specified today all CE marked packets are put in the Low
>>> Latency queue.  In all cases and proposals I have seen any use of
>>> an input of ECT(0) or ECT(1) is lost in any marking strategy, and
>>> that does infact lead to problems that must be handled.
>>
>> [RB] Yes, I know, ECT(0) and ECT(1) get both lost on CE marking and
>> ECT(1) and CE packets are both put into the L4S low latency queue.
>> This is a bit hidden in Section 3 of the ecn-l4s-id draft
>> "A network node that implements the L4S service normally classifies
>> arriving ECT(1) and CE packets for L4S treatment."
>> (I would have expected that it is also mentioned in the l4s-arch draft).
>>
>>>  [RWG] IMHO, that actually does make a fairly strong case for
>>> clasificaiton of HFCC (High Fedility Congestion Control) by
>>> use of a DSCP, and to work forward with getting that DSCP to
>>> traverse large areas.  By use of DSCP it is can be clear that
>>> everyone along the DSCP aware path knows these packets are
>>> from dual congestion (CE/SCE or CE/L4S) controller end nodes.
>>
>> [RB] Yes, but only in combination with the different CE-signal
>> ECT(1) indicating a different marking behavior. Note that,
>> domains that do not support the PHB/DSCP should
>> simply map it to the default PHB while retaining the DSCP
>> (this is the recommended behavior in RFC2474:
>>  "Packets received with an unrecognized codepoint SHOULD be forwarded
>>    as if they were marked for the Default behavior, and
>>    their codepoints should not be changed.").
>> In those domains the default PHB queue may use classic ECN-CE marking.
>> The CE mark is set and the DSCP is retained, but the semantics is not
>> "I got a CE-mark from the L4S queue". This can only be distinguished
>> if we have an unambiguous output signal like ECT(1) that denotes shallow
>> queue marking or the like.
>>
>>>>> <snip>
>>>>>
>>>>> [RB]......It would be better to make DSCPs "work" (at least not bleaching them) instead of creating more and more work arounds.
>>>>>
>>>>>> * SCE (ECT(1) as output) is more intuitive to me.
>>>>>
>>>>> [RB] The nice thing about this is that the output is at least unambiguous:
>>>>> ECT(1) means some/light congestion level (scalable congestion control reaction), CE means traditional indication of congestion (stronger congestion control reaction). Whereas in L4S it is not clear whether CE actually means "classic CE" or "L4S CE".
>>>>>
>>>>
>>>>
>>>
>>
>> Regards,
>>  Roland
>>
>>
>