Subject: [tsvwg] Signaling CE interpretation by a DSCP

From: <[email-masked]>
Date: Tue, 19 May 2020 10:04:41 +0000

Hi Roland,

[RudiG]: Don't know whether that makes sense. If DSCP was not an input to the network, but rather an output ?

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

[RudiG]: That's not well thought through, just an idea.

Regards, Ruediger

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

---

From: Roland Bless <[email-masked]>
Date: Tue, 19 May 2020 14:08:07 +0200

Hi Ruediger,

> [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 standar…

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.

Regards,
 Roland

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 19 May 2020 07:22:44 -0700 (PDT)

Hello Rolland,
	Clarification on how L4S is specified *today*. [RWG]
Regards,
Rod Grimes

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

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

-- 
Rod Grimes                                                 [email-masked]

---

From: Roland Bless <[email-masked]>
Date: Tue, 19 May 2020 22:39:59 +0200

Hi Rodney,

see below [RB].

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

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

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2020 09:12:04 +1200

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.

If we had allocated 5 bits for DSCPs and 3 bits for ECN, life would be different.

Regards
   Brian Carpenter

---

From: Paul Vixie <[email-masked]>
Date: Tue, 19 May 2020 21:35:30 +0000

On Tuesday, 19 May 2020 21:12:04 UTC 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.

we are having trouble establishing the antecedent in all this. instead of 
describing the congestion management problem we have and proposing solutions 
to that, or describing the future expansion possibilities of a system we wish 
to build and proposing encodings that will offer those possibilities, we're 
including in our problem statement the limits of signaling we can add which 
must include existing interpretations of signals we have available.

that's why DSCP isn't domain-specific in the context of this conversation.
 
> If we had allocated 5 bits for DSCPs and 3 bits for ECN, life would be

being honest, i think if we had done that we'd by now have 32 defunct DSCP's 
and eight defunct ECN's, none of which turned out to work at scale, and we'd 
be wishing we had more signal bandwidth so that we could try more new ideas 
without tripping over prior interpretations of various bit patterns.

my takeaway from IEN 145 was "most congestion control ideas will end badly."

-- 
Paul

---

From: Roland Bless <[email-masked]>
Date: Tue, 19 May 2020 23:46:33 +0200

Hi Brian,

> 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…

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

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 19 May 2020 17:13:01 -0700 (PDT)

> 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…

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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2020 15:13:26 +1200

> Perhaps it is also time to consider that.

Well, taking a slight tack here:

Pool 3 (xxxx01) DSCPs are now reserved for standards action. Only one is
allocated (000001) for LE.

It is conceivable to me that we could reserve xxx101 for ECT(1) extensions.

That doesn't change the problem of mutability, although we could of course write the appropriate MUST NOTs in an RFC.

Regards
   Brian Carpenter

---

From: <[email-masked]>
Date: Wed, 20 May 2020 07:03:52 +0000

Brian,

My idea was based on the assumption, that the operator access node indicates its interpretation of ECN bits, if it sets or re-sets them. That DSCP would then be relevant downstream to the terminating equipment. A DSCP as downstream output signal of the access node only. I thought IETF might be able to agree a standard DSCP on that portion of the network. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Roland Bless
Gesendet: Dienstag, 19. Mai 2020 23:47
An: Brian E Carpenter <[email-masked]>; Rodney W. Grimes <[email-masked]>
Cc: [email-masked]
Betreff: Re: [tsvwg] Signaling CE interpretation by a DSCP

Hi Brian,

> 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…

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

>>> 	Clarification on how L4S is specified *today*. [RWG] Regards, Rod 
>>> Grimes
>>>
>>>> Hi Ruediger,
>>>>
>>>> indicating a different PHB (see the AF PHB group for example: 
>>>> marking partially happens according to queue management).
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> 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."
>>> 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.
>>
>> 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:
>> if we have an unambiguous output signal like ECT(1) that denotes 
>> shallow queue marking or the like.
>>
>>>>> <snip>
>>>>>

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 20 May 2020 10:34:09 +0300

> On 20 May, 2020, at 10:03 am, <[email-masked]> <[email-masked]> wrote:
> 

I see where you're going with this.

But what happens if the DSCP is bleached between the AQM and the receiver, which would not be unusual if the AQM is somewhere on the egress path from a consumer ISP?  How is the ECN mark interpreted in that case, and what are the consequences?  I fear you will end up with basically the same set of problems.

 - Jonathan Morton

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 20 May 2020 10:12:23 +0200

Hi Jonathan,

> On May 20, 2020, at 09:34, Jonathan Morton <[email-masked]> wrote:
> 

	[SM] Not necessarily, an L4S receiver could translate such an ambiguous signal simply into an unambiguous one, say a "virtual" drop (the receiver does not need to actually drop the packet, it just needs to pretend a drop tp make the sender fall back to the obvious safe behavior, with SACK the "missing" segment could be later confirmed as received, after sufficient DupACKs to trigger a drop response at the sender). Note that this can be improved upon with more signaling, but I see a clearly safe path using that method. 
	Sure, not redefining CE seems like a better approach in the mid- to long-term (also safer as it does not require active buy-in from the receiver), but L4S seems to not care for clean design and long-term maintainability as much as minimizing hurdles during initial deployment. 

Best Regards
	Sebastian

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 20 May 2020 11:22:03 +0300

> On 20 May, 2020, at 11:12 am, Sebastian Moeller <[email-masked]> wrote:
> 

Well, we are already assuming that the receiver has some way to explicitly signal the distinction between an AIMD and AIAD signal to the sender, that distinction being what the DSCP would now carry.  The precise nature of that mechanism doesn't matter.

But if the DSCP is bleached, the receiver has to assume it's an AIMD signal, as you point out.  So an intended AIAD signal is misinterpreted as an AIMD signal, and if the fairness properties of the AQM rely on that distinction being maintained (as in DualQ), we have the same problem as in DCTCP all over again.  That's what I was trying to highlight.

> 	Sure, not redefining CE seems like a better approach in the mid- to long-term (also safer as it does not require active buy-in from the receiver), but L4S seems to not care for clean design and lo…

Some of us happen to think that basic congestion safety is a hurdle that must be cleared for initial deployment.  So if that is their strategy, it isn't working.

 - Jonathan Morton

---

From: <[email-masked]>
Date: Wed, 20 May 2020 08:47:15 +0000

From: Jonathan Morton <[email-masked]> 
Sent: Mittwoch, 20. Mai 2020 09:34

[RG] >> My idea was based on the assumption, that the operator access node indicates its interpretation of ECN bits, if it sets or re-sets them. That DSCP would then be relevant downstream to the terminating equipment. A DSCP as downstream output signal of the access node only. I thought IETF might be able to agree a standard DSCP on that portion of the network. 

[JM] I see where you're going with this.

[JM]  But what happens if the DSCP is bleached between the AQM and the receiver, which would not be unusual if the AQM is somewhere on the egress path from a consumer ISP?  How is the ECN mark interpreted in that case, and what are the consequences?  I fear you will end up with basically the same set of problems.

A standard/recommended DSCP allows for standard implementations. A "global" roll out takes a while, of course. If a company like the one I'm working for decides to support one of the ECN flavors, and signal that by a standard DSCP on the last mile, I'd guess deployment takes one or two years time (apart from a few legacy devices maybe). If supporting a flavor of ECN is beneficial for customers, operators and third party service providers, it is likely to be picked up by the market over here.

There may be nodes between network operator and consumer still bleaching DSCPs, if these aren't managed by the network operator. But that will not be a general behavior. I could imagine that it takes longer until any new standard (be it ECN related or other) is deployed by these kind of devices. If these devices set the pace for innovation in the Internet, there might not be any. At this place I should add that regulation in Germany requires fixed network access to support all types customer Home Gateways. That requires publication of a national standard on the fixed network access interface. There's a German Home Gateway vendor too, and if an operator picks up a new access feature, the Home Gateway vendor will learn that rather soon and support it for its branded (and non-branded) devices. That might inspire competing Home Gateway vendors.

Regards,

Ruediger

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 20 May 2020 10:48:19 +0200

Hi Jonathan, hi list,

> On May 20, 2020, at 10:22, Jonathan Morton <[email-masked]> wrote:
> 

	[SM] Well, with a safe fall-back, there is all the time in the world for the L4S proponents to make that DSCP transit the internet safely and to come up with a way for the receiver to tell the endpoint what kind of response is desired. One could, for example leave the existing method for CE in place and just signal a 1/p-style signal in say the NS bit.... or one could also demand to carry the dscp back to the sender and the sender to interpret the feed-back only as 1/p style if accompanied by that DSCP..

> Some of us happen to think that basic congestion safety is a hurdle that must be cleared for initial deployment.  So if that is their strategy, it isn't working.

	Why, in the above proposal the default ambiguous case defaults to the obvious safe response (rfc3168-style MD). Will that be optimal for the LL-queue? Obviously not, but that is the price for safety.

Best Regards
	Sebastian

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 21 May 2020 18:20:27 +0100

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

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 21 May 2020 11:08:17 -0700 (PDT)

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.

Regards,
Rod

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 21 May 2020 20:13:30 +0200

Hi Gorry, Rod,

> On May 21, 2020, at 20:08, Rodney W. Grimes <[email-masked]> wrote:
> 
> Gorry,

	[SM] If such broken hardware exists in sufficient numbers to make it prudent to avoid the matter, maybe using URG=0 and the URG pointer bits to encode the relevant counters instead of the reserved bits? 

Best Regards
	Sebastian

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 21 May 2020 19:31:36 +0100

> loss of any data that was in the reserved bit area of the

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. Some decided 
to queue ACKs separately to data, etc.

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 21 May 2020 20:45:13 +0200

Hi Gorry,

> On May 21, 2020, at 20:31, Gorry Fairhurst <[email-masked]> wrote:
> 
> 
> 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?

> 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?

Best Regards
	Sebastian

P.S.: Isn't ACK filtering a pretty strong offense against the end-to-end principle?

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 21 May 2020 20:04:50 +0100

> 	[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…
Try RFC3449, it's old but it's a good generic start. Otherwise you may 
need to look into specific technologies for details.
> 	[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.
> 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

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 21 May 2020 12:26:38 -0700 (PDT)

> 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!

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 22 May 2020 09:53:57 +0200

Hi Gorry,

> On May 21, 2020, at 21:04, Gorry Fairhurst <[email-masked]> wrote:
> 
> 
> Try RFC3449, it's old but it's a good generic start. Otherwise you may need to look into specific technologies for details.

	[SM] Thanks for the pointer, but I confirms my suspicion, with out looking into L4 headers no selective processing of ACKs possible. ACK decimation as in section 5.2.2, seems like a rather blunt tool likely to do more damage than good, and lo and behold, the RFC recommends L4-aware ACK filtering over more L4-agnostic ACK decimation.

> A short router queue doesn't look at L4 headers, nor does one that does separate queues based on size of packet.

	[SM] Fair enough, but that is not ACK specific anymore, no? And as the RFC indicates tis is likely to do quite some harm to TCP flows traversing such a bottleneck. For once, thank $DEITY that L4S did not jump on that boat and mandates extra-harsh dropping/marking for small packets.

> "Offence" if you like - but that seems to be rather a strong word.

	[SM] Why? By employing ACK filtering the network pretends to know better than the endpoints, so strong wording seems appropriate. Now, if ACK filtering generally would be implemented such, that only packets that essentially only differ in the acknowledgment number would be "merged", the network could claim that it would truly only reduce the ACK redundancy a bit (with the positive effect for the endpoints of ameliorating ACK compression). But with the failures reported here, of making sure that the other bits are equal ACK filtering seems more like another way of protocol ossification (and and argument for encrypting TCH headers, but I digress). 

> Protocols that send too many ACKs and too much ACK data feel pain.

	[SM] But they would feel the pain, even if the network dod nothing to lighten the ACK load, no?

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

	[SM] Sorry, I disagree, if my application behaves stupidly, it can expect sub-optimal service by the network (that is bear the consequence of overloading the reverse channel)). The network silently trying to clean up an applications mess results in a) the application never feeling selective pressure to remedy its design flaw, b) the network ossifying the transport protocols.

> Personally, I think protocols could be designed to send less, RTP often is used like that, QUIC isn't yet, but could be.

	[SM] +1: but that is IMHO again in line with the e2e principle, the solution for endpoints doing stupid things is fixing the endpoints. Just as the solution of the network doing stupid things is fixing the network (like e.g. fixing the dual queue coupled AQMs broken sharing behaviour at short RTTs in the network elements and not by adding a crutch to TC{P Prague that might get the misdesaign past the IETF but that will probably be disabled in real-life roll-out (or simply not implemented at all in alternative L4-protocols to use the dual queue coupled AQM))

Best Regards
	Sebastian

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 22 May 2020 09:05:58 +0100

> 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…
That seems a little unfair, since section 5.2.1 for example does say 
things like:
"

    it should avoid deleting a series of 3 duplicate
    ACKs that indicate the need for Fast Retransmission [RFC2581] or ACKs
    with the Selective ACK option (SACK)[RFC2018] from the queue to avoid
    causing problems to TCP's data-driven loss recovery mechanisms."

And that was why ACK decimation was deprecated, although that's still 
used. I agree though, if written now, it could say more about ECN, and 
IPv6 extensions, etc. if we wanted to update that advice, we could. 
There is I think also generally more tolerence now to stretch-acks in 
TCP stacks.

What I was suggestin that we seek to make a transport robust to such loss,
because although the IETF does advise against ACK decimation, ACKs-first 
Scheduling, etc, there still can be ACK loss.

Gorry

-- 
G. Fairhurst, School of Engineering