Opened 3 years ago

Closed 2 years ago

#18 closed defect (fixed)

Loss detection in time units

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

Description (last modified by wes@…)

There are concerns with the current requirement in the L4S ID document that L4S transports need to perform loss detection in time units.

This was discussed at IETF 105 (issue "C").

This is the so-called "RACK requirement" (though it does not actually say that RACK itself is required).

David Black raised this issue on-list, at IETF 105, and in prior meetings as a concern.

Change History (8)

comment:1 Changed 3 years ago by wes@…

  • Description modified (diff)

comment:2 Changed 3 years ago by gorry@…

The main concern I noted on this topic was to clearly decide if the L4S decription can specify that it relaxes the in-order delivery requirements of the transport service. I have argued that this is in itself a separate experiment and as far as I know was not chartered by TSVWG.

Specifically this concerns this text in L4S-ID and related statements on what is permitted within the L4S experiment:

link technologies that support L4S can remove the head-of-line blocking delay they have to introduce while trying to keep packets in tight order to avoid triggering loss detection based on counting packets.

On a personal note, I have no issue with the proposal for a transport that makes a switch to time-based units, and understand that logic.

comment:3 Changed 3 years ago by gorry@…

The first decision seems to be whether this experiment is in-scope of this work item.

Last edited 3 years ago by gorry@… (previous) (diff)

comment:4 Changed 3 years ago by…

The latency benefits of L4S appear to apply Internet-wide, as bottleneck queues could in principle occur anywhere. In contrast, the head-of-line blocking delay removal benefits appear to be link-technology specific. In particular, there appear to be significant benefits for RF and wireless link technologies whose reliability may vary by lane within a multi-lane link. However, there seems to be little if any benefit for optical fiber links, e.g., as used in data centers and WANs.

Hence, the justification for an Internet-wide experiment with link head-of-line blocking delay seems weak; such an experiment (which was not part of the L4S scope when the drafts were initially adopted by the working group) ought to focus on network link technologies that derive clear benefits from removal of head-of-line blocking delay. I agree with Gorry that time-based loss detection is a good thing overall for transport protocols - what I question is its inclusion as a necessary element of the latency-centric L4S experiment.

comment:5 Changed 3 years ago by ietf@…

There is no proposal for "an Internet-wide experiment with link head-of-line blocking delay".

Rather, the proposed requirement is designed not to preclude future experiments with head-of-line blocking delay (whether local or Internet-wide).

Senders already have an incentive to detect loss in time units - it gives better performance. So there's no harm mandating time based units (assuming the text is crafted to avoid the controlled environment problem).

Without the requirement there would always be uncertainty that some L4S flows in any link might be detecting loss by packet counting. That unnecessary uncertainty would preclude any future experiments in this space.

comment:6 Changed 3 years ago by…

There is no proposal for "an Internet-wide experiment with link head-of-line blocking delay".

Then (as an individual) I would expect to see text changes to remove (or at least significantly relax) the prohibition on use of 3DupACK with L4S. That's the internet-wide aspect in a nutshell.

comment:7 Changed 3 years ago by…

Based on discussion at IETF-106 (Singapore), the direction to close this issue is to make the requirement that loss be detected in time units become a "SHOULD" requirement instead of a "MUST" requirement on the basis that this is a "good thing" (tm) for the Internet in general, but is not an absolute necessity for the L4S low latency service to work.

comment:8 Changed 2 years ago by wes@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.