Subject: [tsvwg] L4S CC-signaling and tunneling

From: Sebastian Moeller <[email-masked]>
Date: Mon, 27 Apr 2020 10:58:29 +0200

Dear List,

after Bob's recent emphasis on L4S's conscious design to be operable with its AQM operating on tunneled traffic, I took the liberty to actually look at the three currently discussed L4S RFC drafts. All I found when searching for tunnel and/or encap* was the following in https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-06:

"6.3.4.  Other Potential Deployment Issues

   An L4S AQM uses the ECN field to signal congestion.  So, in common
   with Classic ECN, if the AQM is within a tunnel or at a lower layer,
   correct functioning of ECN signalling requires correct propagation of
   the ECN field up the layers [RFC6040],   [I-D.ietf-tsvwg-ecn-encap-guidelines]."

I am a bit puzzled how terse this description is given how much emphasis there seems to have been on making L4S congestion signaling work properly with tunnel layers. While I am loath to propose to inflate the L4S drafts any further, maybe some fat could be trimmed at other places to make some room for a more detailed description of the desired/required tunnel transition properties.

Best Regards
	Sebastian

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Apr 2020 09:04:26 +0000

Hi Sebastian,

Both RFC6040 and draft-ietf-tsvwg-ecn-encap-guidelines discuss this extensively and L4S is inline with the use of the ECN markings as assumed in the these documents. I believe this is well covered for L4S (while SEC might need some addition consideration as using ETC(1) as an output signal is entirely new). Or which things are you missing in these documents? 

Mirja

On 27.04.20, 10:58, "tsvwg on behalf of Sebastian Moeller" <[email-masked] on behalf of [email-masked]> wrote:

    Dear List,

    Best Regards
    	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 27 Apr 2020 11:27:34 +0200

HI Mirja,

> On Apr 27, 2020, at 11:04, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Sebastian,
> 

	I am missing one or two paragraphs that clearly summarize why L4S-AQM on encapsulated traffic is going to be an important use-case (and why) and why L4S design does the right thing in that regard. 
	The text as cited below seems to work verbatim for SCE as far as I can tell, according to https://tools.ietf.org/html/rfc6040#page-9 on encapsulation the future inner header is copied to the outer header so everything is conserved there, and on decapsulation figure 4 seems to work well for SCE, but not L4S as it seems to indicate that inner ECT(0) might be escalated into ECT(1) on decapsulation (if the outer header had ECT(1)), what am I missing? My point is I should not be asking these questions after reading the RFC, as is the section cited below really does not clear things up for me, does it for you?

Best Regards
	Sebastian

P.S.: This here is not about what I like or dislike, this is about the RFC being made as clear and unambiguous as necessary.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Apr 2020 10:37:51 +0000

Hi Sebastian,

Yes, you are right Figure 4 should work well for SCE. I was more worried about "old" implementations that use the table in Figure 2 and might conceal ETC(1) markings. I don't think it's a problem because at some point there would be CE marking and congestion can still be signaled but I think it would be good to mention this case (as these tunnel implementation exists and are deployed out there).

For L4S, rewriting ETC(1) to ETC(0) at tunnel egress is not different from any other node in the network doing this directly (without a tunnel in between). So I don't think this need to be addressed for tunnels separately.

Mirja

On 27.04.20, 11:27, "Sebastian Moeller" <[email-masked]> wrote:

    HI Mirja,

    
    Best Regards
    	Sebastian

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 27 Apr 2020 13:46:08 +0300

> On 27 Apr, 2020, at 1:37 pm, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 

I agree that tunnels are something we have not explicitly addressed in the draft, and that could be a point of future improvement.  And you are correct that if the SCE signal is erased on the path (for any reason), the result is still "effective congestion control", even if not "high fidelity congestion control".

> For L4S, rewriting ETC(1) to ETC(0) at tunnel egress is not different from any other node in the network doing this directly (without a tunnel in between). So I don't think this need to be addresse…

But the network is generally supposed to preserve the ECT(x) distinction.  That is what ECN Nonce was going to rely upon to verify the correct handling of CE.  In the event, ECN Nonce was not required, but…

My point is that if a tunnel actively erases ECT(1), that is a special problem of the tunnel, not of the general Internet.  If it is likely to occur, then L4S would be more affected by it than SCE, because it has the potential to prevent "effective congestion control" of an L4S flow at an L4S bottleneck, due to the use of ECT(1) as a classifier.

 - Jonathan Morton

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 27 Apr 2020 12:13:53 +0100

> My point is that if a tunnel actively erases ECT(1), that is a special problem of the tunnel, not of the general Internet.  If it is likely to occur, then L4S would be more affected by it than SCE,…

I don't follow that, maybe I missed something: If a path erases ECT(1)-> 
NECT, or a policy implements such a remarking, then no more L4S marking 
to CE will occur later in this path, but more significantly, the L4S 
transport will no longer be relevant.

Wouldn't absence of a ECT(1) marking cause the flow to transition to not 
using L4S transport semantics?

Gorry

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 27 Apr 2020 15:41:26 +0300

> On 27 Apr, 2020, at 2:13 pm, Gorry Fairhurst <[email-masked]> wrote:
> 
> I don't follow that, maybe I missed something: If a path erases ECT(1)-> NECT, or a policy implements such a remarking, then no more L4S marking to CE will occur later in this path, but more significantly, the L4S transport will no longer be relevant.

It means the L4S queue downstream of the tunnel would not see the L4S classifier, and would perform ECN marking according to RFC-3168, which (ignoring the heuristic for now) would result in conventional traffic being squeezed out of that same queue.

I ignore the heuristic because, although it works sometimes, it is not very reliable, so from a congestion control safety perspective, it is wise to consider the worst case.  So far, it is also not normatively specified within (nor is such a normative specification referred from) the L4S drafts.

> Wouldn't absence of a ECT(1) marking cause the flow to transition to not using L4S transport semantics?

I haven't seen any evidence of that behaviour being specified or implemented in L4S.  But you may correct me if I've simply missed it.  There is an awful lot of text to trawl through in the L4S draft set.

At any rate, it is clear that the situation with tunnels is fairly complex, and we should really have a more thorough discussion about them, ideally with some proper evidence about how real tunnels behave and some idea of whether they are likely to follow updated specifications if we produce them.  Unfortunately, an earlier attempt to do so got derailed very quickly and was not productive.  Trying to rehash all those arguments in the hours immediately preceding a meeting is also not very productive.  So can we save this for later?

 - Jonathan Morton

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 27 Apr 2020 13:47:57 +0100

> At any rate, it is clear that the situation with tunnels is fairly complex, and we should really have a more thorough discussion about them, ideally with some proper evidence about how real tunnels…

I agree to park this. I think we just need to decide on which usage of 
ECT(1) the IETF will progress.  From there we can work on tests and 
specifications, pursuing two lines of examination is difficult, if not 
impossible using our current method of WG operation.

Gorry