[LOOPS] Packet sequence numbers

[Carsten Bormann <[e-mail]>]

In the process of preparing the next version of the gen-info draft, there are a few items where it probably would be good to get wider input.

One of these is the use of packet sequence numbers.

Gen-info says that the packet sequence number (PSN) counts the LOOPS packets transmitted by the LOOPS ingress, i.e., that retransmissions receive a new PSN.

This removes ACK ambiguity: the situation where original transmission and retransmissions carry the same sequence number and an ACK therefore cannot be unambiguously assigned to one of the transmission never occurs.

Disadvantages may include:

* Without additional information, the original sequence of the packets is no longer visible at the egress.  This means that not enough information is available to perform resequencing at the egress.  (Resequencing is not a feature of LOOPS, but could be easily added by an implementation if overall latency is not an issue and enough information is available at the egress.)

* FEC will not be able to derive a lot of information from the packet sequence number, so will need some additional information, too.

* Monitoring tools that are looking at the PSN will simply see the holes created by the losses on the LOOPS segment and not the successful repair actions.  (But the same is true for FEC, so maybe these monitoring tools are too simple.)

Advantages may include:

* No ACK ambiguity.

* The need for back-filling ACK bitmaps is limited to the time scale of reordering (if any at all).

* Somewhat simplified implementation: NACKs for sequence numbers that already have been retransmitted don’t need a hold-off — the cached packets are simply swept to their new numbers at the ingress and repetitions of old NACKs can be ignored.  On the other hand, some retransmission counter will need to be on each packet to avoid 1-persistence.

One question that comes up about implementation is how likely a “single retransmission” optimization will be: An implementation that only ever retransmits a packet once can simply delete the cache entry after retransmission instead of sweeping it to the new number.  Single retransmission actually fits many usage scenarios well, as it essentially squares the non-delivery reliability for random losses, which may be all that is needed.

Opinions?  Should LOOPS be more like QUIC or like protocols that have been around for a few decades?

Grüße, Carsten