Re: [tsvwg] Signaling CE interpretation by a DSCP

["Rodney W. Grimes" <[e-mail]>]

> On 21/05/2020 19:45, Sebastian Moeller wrote:
> > Hi Gorry,
> >
> >
> >> On May 21, 2020, at 20:31, Gorry Fairhurst <[e-mail]> wrote:
> >>
> >>
> >> On 21/05/2020 19:08, Rodney W. Grimes wrote:
> >>> Gorry,
> >>> 	Would you care to expand on "different flavours of
> >>> reducing ACKs in different scenarios"?  DACK, SACK and RACK
> >>> are end node implementations of this and already deal well
> >>> with ECN bits.
> >>>   As far as I am aware the only real issue
> >>> that any HFCC must deal with is the hardware that thins
> >>> acks by simply using the most recent one, often with the
> >>> loss of any data that was in the reserved bit area of the
> >>> TCP header.
> >> Some network ACK Filtering is by managing the drops from the end of a short router queue, some is much more sophisticated, dictated by the layer 2 infrastructure it is supporting, e.g. linked to radio/capcacity resource management. I'd expect some to be able to parse headers, while other methods certainly do not peek into level 4 headers.
> > 	[SM] Intrigued, how is that supposed to work? As far as I can tell an ACK is a L4 construct, so how do I "merge" ACKs without first identifying that the candidate packts truely are ACKs and how to decide which is more "recent" without looking into the L4 header?
> Try RFC3449, it's old but it's a good generic start. Otherwise you may 
> need to look into specific technologies for details.

I was specifically addressing a deficit in RFC3449 in that it does not address the very issue of certain bit changes between acks should not be loss, this is infact what casues L4S, and SCE and any other protocol trying to use TCP bits of an ACK packet to feedback congestion.  I still do not see how anything in RFC3449 addresses SM's, and now my, assertion that you can not do ACK filtering/compression/anything *WITHOUT* layer 4 inspection, you must determine it is an ACK packet!

> >> Some decided to queue ACKs separately to data, etc.
> > 	[SM] Sure, but to do even that one needs to first detect that a packet is an ACK, no?
> A short router queue doesn't look at L4 headers, nor does one that does 
> separate queues based on size of packet.
> > Best Regards
> > 	Sebastian
> >
> > P.S.: Isn't ACK filtering a pretty strong offense against the end-to-end principle?
> 
> "Offence" if you like - but that seems to be rather a strong word. 
> Protocols that send too many ACKs and too much ACK data feel pain. It's 
> not that offensive when it reduces your service cost or helps you use 
> zoom/webex/skype while someone in your house watches 
> netflix/youtube/etc. Personally, I think protocols could be designed to 
> send less, RTP often is used like that, QUIC isn't yet, but could be.
> 
> Gorry
> 
> >
> >>> Regards,
> >>> Rod
> >>>
> >>>> On 20/05/2020 01:13, Rodney W. Grimes 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.
> >>>>> Well it was coupled with "on the last mile" so that didnt make me blink.
> >>>>>
> >>>>>> If we had allocated 5 bits for DSCPs and 3 bits for ECN, life would be different.
> >>>>> Perhaps it is also time to consider that.
> >>>>>
> >>>>> Given the issues faced, and what L4S attempts to do, it might be best to
> >>>>> stop trying to do all things everywhere in one set of changes.
> >>>>>
> >>>>> L4S "fixes" that are, IMHO, to far reaching:
> >>>>> a)  Dealing with the Ack thinning issue.
> >>>>> 	We should go write an ack thinning RFC that fixes most of
> >>>>> the issues here.  Mainly it is that acks are thinned ignoring any
> >>>>> values that may be assigned in the reserved bits.  A simple fix of
> >>>>> saying that one MUST NOT thin acks that have differening values in
> >>>>> the reserved bits would go miles to solve some of these issues.
> >>>> Alas, I think that could be a naive view of the different flavours of
> >>>> reducing ACKs in different scenarios.
> >>>>> b)  Classification of traffic by use of ECT(1) as a traffic
> >>>>>       Classifier so it can traverse the internet.
> >>>>>
> >>>>> 	Here our efforts, and I know I am going to get a lot of
> >>>>> no's on this, might be best spent working on DSCP and getting
> >>>>> the RECOMMENDED upgraded
> >>>>>
> >>>>> c)  Redefinition of the CE mark so that HFCC traverses all things
> >>>>>       internet (aka the Tunnel issue.)
> >>>>> 	Lets get the tunnels fixed, sure it might take a decaded
> >>>>> for all the straglers but I do believe a huge number of these
> >>>>> would be fixed rather quickly by a handful of common code base
> >>>>> changes (wiregaurd has already made a fixed based on some feed
> >>>>> back that occured in the last month from tsvwg.)
> >>>>>
> >>>>> d)  Provide ultra-low latency and high throughput.
> >>>>> 	It has been demonstrated that the algorithims in
> >>>>> the current prototype L4S is in-tollerent of jitter/burstiness,
> >>>>> the required heuristics are to fragile.
> >>>>>
> >>>>> In summary:
> >>>>> 	Do one things and do it well, usually if you try to
> >>>>> do 2 things at once (or in this case with 1/2 a code point)
> >>>>> you do nothing very well.  Try to do 4 things at once....
> >>>>>
> >>>>> 	I think it is time the WG take a seriously hard
> >>>>> look at the number of hard problems L4S is trying to solve
> >>>>> all in one get go.  Any one of these problems taken in
> >>>>> issolation is difficult.
> >>>>>
> >>>>> Regards,
> >>>>> Rod
> >>>>>
> >>>>>> 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
> >>>>>>>
> >>>>>>>
> 

-- 
Rod Grimes                                                 [e-mail]