Re: [tsvwg] L4S: Guard DSCP

[[e-mail]]

Hi David,

maybe I missed an important point, but isn’t the intent of the Guard DSCP to inform the receiver about the meaning of a set ECN bit? My take is, if Domain decides to go for an experiment, Domain should be conservative with what they send to peers and configure suitable re-marking policies to set default DSCP/ECN 00 at interconnection, unless they know their peer is happy to participate in the L4S experiment too. What I also expect is that a few domains are liberal with what they send and forward traffic with a bunch of DSCPs, without setting up any kind of formal or informal agreement with their peers.

If the Guard DSCP is in range 000 xxx, it will pass some networks at least. Maybe that’s a way forward.

Regards,

Ruediger


Von: tsvwg <[e-mail]> Im Auftrag von Black, David
Gesendet: Montag, 26. April 2021 22:46
An: C. M. Heard <[e-mail]>; Jonathan Morton <[e-mail]>
Cc: TSVWG <[e-mail]>
Betreff: Re: [tsvwg] L4S: Guard DSCP

[Still posting as an individual]

If ECT(1) is to be remarked, I agree with Sebastian's earlier comment that the robust remarking would be to Not-ECT:


> Not-ECT should work as downstream non-L4S bottlenecks will simply drop packets to signal congestion, to which L4S-compatible protocols

> are required to respond (but so are general internet wide used protocols, and still BBR does not do so immediately).

However, this entire discussion is disheartening, as the end-to-end usability of the ECN field, and in particular the ECT(1) value was a major L4S rationale for using ECT(1) by itself to indicate the low-latency service.  It would be rather unfortunate (IMHO, as an individual) if the L4S experiment were to result in widespread bleaching of ECT(1) to Not-ECT.

Thanks, --David

From: C. M. Heard <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, April 25, 2021 11:55 PM
To: Jonathan Morton
Cc: Pete Heist; Sebastian Moeller; Black, David; TSVWG
Subject: Re: [tsvwg] L4S: Guard DSCP


[EXTERNAL EMAIL]
On Sun, Apr 25, 2021 at 4:44 PM Jonathan Morton wrote:
On 26 Apr, 2021, at 1:46 am, C. M. Heard wrote:

As mentioned above (and in draft-ietf-tsvwg-ecn-l4s-id-14 Section4), AccECN is a required part of L4S when the transport is TCP. Note that AccECN provides a means to echo back to the sender of a SYN whether the SYN contains not-ECT, ECT(0), ECT(1), or CE, if AccECN is negotiated (see draft-ietf-tcpm-accurate-ecn-14 Section-3.1.2 and in particular the first for lines of Table 2). Note further that draft-ietf-tsvwg-ecn-l4s-id-14 Appendix A.2.1 explicitly urges that L4S implementations set ECT(1) on SYN segments. Based on this, it should be possible for an L4S connection initiator to determine whether ECT(1) was bleached before its SYN was sent onward to a remote endpoint that supports AccECN. That is enough to tell it to fall back to RFC 3168 compatibility mode for that connection,

There are two big holes in this idea:

1: Some middleboxes discard unknown TCP options.  A path on which this occurs prevents AccECN from giving feedback about anything beyond the count of CE marks received, using the ACE field.  If passage of the option were required for AccECN to work, the ACE field probably wouldn't be in the spec.

A middlebox stripping the option is not really a problem, since AccECN negotiation relies entirely on the ACE field. Indeed, the initial SYN does not contain the option at all -- see draft-ietf-tcpm-accurate-ecn-14 Section 2.1.

2: What happens if the CE mark is applied to the SYN *after* it has passed the border guardian?  The receiver cannot distinguish which ECT codepoint was originally on it in that case, so the information added by the guardian is lost.

I did indeed fail to consider this case. It can be addressed, though there is an issue with the solution. The originating TCP will get an ACE field of 110 in the SYN-ACK, meaning AccECN / CE on SYN, which is indeed ambiguous. The safe thing for the originating TCP to do would be either to fall back to RFC 3168 compatibility mode unconditionally or to look at the guard DSCP to decide whether or not to do so. Looking at the guard DSCP allows the originating TCP to determine whether or not it is communicating with another L4S TCP in the domain and avoid the unnecessary fallback behavior in that case. Similar remarks apply for the case of a simultaneous open.

The issue with this solution is that inspection of the DSCP by the transport layer to avoid suboptimal behavior within the L4S domain (i.e., fallback to classic when an ECT(1) SYN is marked with CE) violates the David's desideratum Y:

DON'T

X.      Require AQMs to use Guard DSCP in addition to ECT(1) to identify L4S traffic.   This should be allowed, not required, which is already the case - see Section 5.4 of the ecn-l4s-id draft.

Y.      Rely on DSCPs for signaling or modify transport protocols to have reactions that vary by received DSCP.

Z.      Do anything else that would be a significant obstacle to removing use of the Guard DSCP if the L4S experiment succeeds.
I might also add that the business of falling back to RFC 3168 behavior based on what is in a SYN-ACK (or SYN) is not needed not needed to communicate with an endpoint in the L4S that supports AccECN but not L4S; indeed, in that situation precludes the possibility of L4S congestion control in one direction and classic RFC 3168 congestion control in the other direction. It's not clear how important that case is, though.

Mike Heard