Opened 2 years ago

Closed 17 months ago

#20 closed defect (fixed)

Objection to ECT(1) codepoint usage

Reported by: wes@… Owned by: draft-ietf-tsvwg-l4s-arch@…
Priority: major Milestone: L4S Suite - WGLC Preparation
Component: l4s-arch Version:
Severity: - Keywords:
Cc:

Description (last modified by wes@…)

The current L4S ID proposal is to use ECT(1).

There are objections to this, and other proposals mentioned, including:

  • DSCP
  • new protocol number
  • combination of DSCP and ECT(1)?

All of these alternatives are discussed in the draft, and some time ago the working group converged on ECT(1) use (aka "Berlin consensus").

Another proposed use of ECT(1) under consideration is SCE, and these seem to have trouble coexisting.

This was discussed at IETF 105 (issue "E"), and raised at the open microphone by Pete Heist, who would like to revisit the Berlin consensus.

If ECT(1) is used for L4S ID, there should be a clear understanding of to what extent this precludes experimenting with SCE, what problems could result, and what the recommended approach would be to enable separate safe experiments with each.

Change History (10)

comment:1 Changed 2 years ago by wes@…

  • Description modified (diff)

comment:2 Changed 2 years ago by chromatix99@…

At one point there was a suggestion that the NQB DSCP also being proposed could be used to identify L4S traffic, instead of ECT(1). However, this idea has since been rejected through discussions on the list. It is still possible that another DSCP could be proposed for this purpose.

An advantage of using a DSCP is that it would become feasible to contain L4S traffic to networks designed to handle it, a measure that may prove necessary if the existing deployability concerns are not adequately addressed. If ECT(1) continues to be used as the L4S ID, that measure could not be implemented without impeding use of those networks by other possible uses of that codepoint, such as SCE.

Otherwise, the direct conflicts between SCE's and L4S' uses of ECT(1) appear to have only minor consequences. SCE endpoints will not negotiate the use of AccECN which is required by L4S, so SCE flows won't normally carry ECT(1) except as an SCE signal. ECT(1) marks applied by SCE AQMs will not be applied to L4S traffic (which is already ECT(1) or CE marked), and will have similar effect on mis-classification into L4S queues as CE marked packets within ordinary RFC-3168 flows.

comment:3 Changed 2 years ago by ietf@…

I believe this issue of coexistence between L4S and SCE only arises if issue #16 (L4S - Interaction w/ 3168-only ECN AQMs) is not resolved? So shouldn't this issue be closed and only reopened if #16 is not resolved?

comment:4 follow-up: Changed 2 years ago by chromatix99@…

No, I think this should remain open at least until #16 is resolved, whether successfully or not. Then the discussion will be better informed.

comment:5 follow-up: Changed 2 years ago by jholland@…

I reviewed the notes and video from the IETF 96 tsvwg sessions and l4s bof, but did not see a consensus call on the use of ECT(1) in any of those rooms, nor on the list within the following few months. I believe I even saw some objections raised.

Maybe I missed it, so I thought I'd ask for a reference: Was there a point when consensus was established supporting the use of ECT(1)? Or has it only been that the objections so far have not been sufficiently strenuous to demonstrate a lack of consensus?

comment:6 Changed 2 years ago by pete@…

Thanks for the comments. I would also like to know more about how the consensus was arrived at, and would hope that there's still more time to formulate scenarios that demonstrate problems with this, which may exist separately from #16.

comment:7 Changed 2 years ago by ietf@…

It is not reasonable to ask for an issue to be resolved without describing something that can be solved. Issue #16 does that. This one does not.

Even if a second issue with the L4S codepoint were formulated, it would not be useful to keep this issue open as well, which would merely hold open more issues just to remark that two other issues to do with codepoints exist.

comment:8 in reply to: ↑ 4 Changed 2 years ago by ietf@…

Replying to chromatix99@…:

No, I think this should remain open at least until #16 is resolved, whether successfully or not. Then the discussion will be better informed.

If issue #16 were resolved, there would be no need for discussion of this issue.

SCE's need for a codepoint is not in itself a meaningful 'issue'. It depends on what SCE is trying to achieve, and whether there is consensus that the IETF wants to achieve that, and whether the IETF's existing chartered work is already likely to achieve something as good or better.

comment:9 in reply to: ↑ 5 Changed 21 months ago by moeller0@…

Replying to jholland@…:

I reviewed the notes and video from the IETF 96 tsvwg sessions and l4s bof, but did not see a consensus call on the use of ECT(1) in any of those rooms, nor on the list within the following few months. I believe I even saw some objections raised.

Maybe I missed it, so I thought I'd ask for a reference: Was there a point when consensus was established supporting the use of ECT(1)? Or has it only been that the objections so far have not been sufficiently strenuous to demonstrate a lack of consensus?

Same here, the IETF96 sessions as far as I understand from http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-l4s?useMonospaceFont=true&showChat=false and http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-tsvarea?useMonospaceFont=true&showChat=false did not have a poll on the ECT(1) question at all:

10. Polls - Chairs

- Lars: do people believe that they understand the proposal being brought forward?
* rough consensus for understanding

- Lars: do you believe this is something the IETF should take on
* stong consensus for yes
- Lars: show hands if you want to help with the work
* approximately 20 hands up.  Send an email to tcpprague@ietf.org if you are willing to help.  State if you are willing to review documents.
- Jana: question about who is willing to deploy.
- Lars: please show your hand if you build equipment or run networks
* 15-20 hands

- Mirja (?) : do people believe that the IETF is able to do this work?
- Lars: if you believe, please hum
* strong consensus yes
- Jana: different pieces: dual-Q, response
- Jana: does tcpprague belong in iccrg?
- Mirja: the only thing that really needs standardization is the marking to discriminate DCTCP vs. classic
- Phil: Koen will show demo now.

No explicit poll about ECT(1), and als no discussion about the different alternatives to using ECT(1) as listed in the L$S-arch draft. I would have thought that reaching an educated consensus would have required an actual discussion of the merits of the different alternatives.

Could anybody share how and where the Berlin consensus was reached and what exactly Berlin consensus refers to, please?

It seems the identifier question was first posed at ietf95 and also did not get a consensus poll then and there. And by ietf97 the question appears to have been settled (and three L4S drafts were adopted en block by hum).

Edit: Stopped one ietf meeting too early, this seems to have been adopted at ietf98, without a explicit discussion of the pros and cons of the proposed ECT(1) overloaded both as an indicator that a flow promises to respond to CE markings in a 1/p mode as well as a intention marker of a flow to request the L4S queue. I note that that seemed to have happened in Chicago.

Last edited 21 months ago by moeller0@… (previous) (diff)

comment:10 Changed 17 months ago by wes@…

  • Resolution set to fixed
  • Status changed from new to closed

A virtual interim meeting was held to discuss if TSVWG should be pursuing use of ECT(1) as an input to support queue selection, or as an output to support increased fidelity of congestion signalling.

Following this, a consensus call was put to the mailing list: https://mailarchive.ietf.org/arch/msg/tsvwg/rXWRHAyGOuu_qOGM3JkpK9whdS4/

The working group feedback confirmed that we should proceed with ECT(1) as an input, and continue the work to evaluate L4S safe use of this within the scope of the other issues.

Note: See TracTickets for help on using tickets.