Opened 11 months ago

Last modified 8 months ago

#19 new defect

Single codepoint for both low latency & resequencing tolerance

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

This is related to the issue of loss detection in time units being required.

The current codepoint proposal indicates that the L4S flow meets the TCP Prague requirements, and that it's both:

  • desiring low-latency (so non queue building)
  • tolerant of reordering / resequencing errors / lack of resequencing

There has been a concern about latching these properties together.

This was discussed at IETF 105 (issue "D"). David Black raised this as a concern of his at the open microphone.

Change History (3)

comment:1 Changed 11 months ago by wes@…

  • Description modified (diff)

comment:2 Changed 8 months ago by ietf@…

The purpose of the new codepoint is to enable an architecture for Low Latency Low Loss Scalable throughput (L4S), not solely Low Latency (which would just be 'LL').

The scalable throughput property has not been stressed as much, because it offers only "delayed gratification" whereas low latency and low loss provide immediate gratification. Nonetheless, scalability is the essence of the L4S architecture (and of course it must always be the essence of the Internet).

The defining condition for setting ECT(1) in draft-ietf-tsvwg-ecn-l4s-id is... a scalable congestion control. That means its rate should be able to scale indefinitely, which requires that the "average number of control signals (ECN marks) per round trip remains roughly constant for any flow rate".

Scaling to any flow rate is also why the draft requires loss detection to be measured in time units. Otherwise, if packet counting is used, spurious loss detection will increase as flow rate scales.

And happily, the scalable property does not require any other property to be compromised (assuming the text is crafted to avoid concerns over controlled environments).

Beyond that, no technical reason has been advanced against loss detection in time units. All the arguments (including the present issue) have been purely procedural.

There is no excuse for anyone at the IETF to put procedure above a scaling requirement.

Last edited 8 months ago by ietf@… (previous) (diff)

comment:3 Changed 8 months ago by david.black@…

Beyond that, no technical reason has been advanced against loss detection in time units. All the arguments (including the present issue) have been purely procedural.

(as an individual) That's not correct - an important technical reason that has been advanced is that lots of "running code" doesn't do that. Treating most of the Internet as a "controlled environment" is an odd way to define the scope of an Internet-wide experiment. Perhaps the newly crafted text will better address this concern.

Note: See TracTickets for help on using tickets.