Opened 3 years ago

Last modified 3 years ago

#21 new defect

CE codepoint semantics

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

There has been a concern that L4S changes CE semantics. Since a TCP Prague flow uses finer grained feedback, more CE marks are expected, and a less severe response function is used.

This is basically RFC 3168 versus DCTCP usage of CE.

With L4S queues and classical 3168 queues in the path, there will be a mixture of CE marks with different semantics.

This was discussed at IETF 105 (issue "F"). Jonathan Morton specifically mentioned it as a concern at the open microphone.

This is related to issue A (interaction w/ RFC 3168-only AQMs).

Change History (6)

comment:1 Changed 3 years ago by wes@…

  • Description modified (diff)

comment:2 Changed 3 years ago by chromatix99@…

This is strongly related to issue #16.

TCP expects to see one congestion signal (either a CE mark or a loss event) per several RTTs, the expected interval between events increasing with BDP to maintain an amortised steady state. For standard Reno, the required interval is cwnd/2 RTTs, where cwnd is dimensioned in segments; other CC algorithms may expect different intervals. A single CE mark is taken as a command to perform a Multiplicative Decrease in the AIMD cycle established since the 1980s.

L4S expects to see two CE marks per single RTT to maintain a steady state. A single CE mark is taken as a command to reduce the cwnd by half a segment. Compared to existing practice, this is clearly a substantial change in the semantic definition of CE.

Notably, the only mechanisms L4S has to command a Multiplicative Decrease by AQM action are a continuous high rate of CE marking (100% marking performs a 50% reduction of cwnd per RTT), or packet drops (which are interpreted the same way as in TCP).

The consequence of this is that conventional, RFC-3168 compliant TCPs sharing a queue and AQM instance with an L4S flow will collapse to near minimum cwnd in response to the signalling rate needed to control the L4S flow. This is regardless of the type of AQM employed, if it applies equivalent signals to both flows, as all existing and deployed AQMs do.

comment:3 Changed 3 years ago by ietf@…

As the last para above demonstrates, this is not just strongly related to issue #16. This is issue #16. There is no need for this separate issue, which ought to be closed.

RFC8311 was published specifically to enable different sender responses to CE marks. That is the well-understood purpose of the IETF's work in this area, because it was recognized that the current standard response does not scale.

comment:4 follow-up: Changed 3 years ago by david.black@…

Writing as author of RFC 8311 to discourage reliance solely on RFC 8311 settle this issue via "proof by authority" - RFC 8311 allows a variety of experimentation with the CE codepoint. Experimental RFC 8511, TCP Alternative Backoff with ECN (ABE), is an example of an additional experiment.

In 20/20 hindsight in a perfect world, DCTCP would have included some way to distinguish DCTCP-class CE marks (1/p congestion response) from TCP-classic-class CE marks (1/sqrt(p) congestion response).

comment:5 Changed 3 years ago by chromatix99@…

I think it would be more accurate to state that #16 and #17 (at least) are natural consequences of this issue.

RFC 8511 (ABE) still essentially defines CE as requesting a Multiplicative Decrease; it only slightly relaxes the former requirement that CE marks should be treated equivalently to packet losses from a congestion-control perspective. Accordingly an ABE-compliant transport is still in steady-state with each CE-marked RTT separated by several unmarked RTTs, and consequently competes reasonably with RFC 3168 compliant transports.

The much more drastic redefinition of CE by DCTCP and L4S changes the character of the message to the point of incompatibility.

comment:6 in reply to: ↑ 4 Changed 3 years ago by ietf@…

Replying to david.black@…:

Writing as author of RFC 8311 to discourage reliance solely on RFC 8311 settle this issue via "proof by authority" - RFC 8311 allows a variety of experimentation with the CE codepoint. Experimental RFC 8511, TCP Alternative Backoff with ECN (ABE), is an example of an additional experiment.

I was not implying that RFC8311 only blesses one experiment. The number of parallel experiments was not limited by RFC8311, because that depends on the specifics of how each experiment could interact with others (or not).

My comment was in response to the concern from chromatix99@… that "Compared to existing practice, this [L4S] is clearly a substantial change in the semantic definition of CE." I referred to RFC8311 merely because its central purpose was to enable experimentation around different ECN marking and different responses to ECN marking.

Nonetheless, I must point out that RFC8311 does not bless any particular experiments itself. Even though RFC8311 referred to L4S and ABE as example experiments, it is the job of experimental RFCs about L4S and ABE to justify their respective experiments.

Note: See TracTickets for help on using tickets.