Re: [LOOPS] Packet sequence numbers

Hi Carsten,

For packet sequence number (PSN) in a retransmit packet, using the old PSN looks more reasonable to me.

When LOOPS uses psn to link an old (lost) packet to a retransmit one, it helps a lot when developing and debugging code. Very straightforward to know if the retransmission for a specific packet works in a way as designed. And also makes troubleshooting easier when it goes to commercial version in my opinion.
Otherwise, we have to guess, e.g. packet 10 is a retransmit for packet 2, and packet 11 is a retransmit for packet 4, takes more effort for developer/tools.

QUIC uses a new packet number for a retransmit packet. At the same time, stream id and offset field can help to easily identify what have been retransmitted. However LOOPS does not look into the data. So it would be preferable to  make LOOPS header information more self-descriptive on which packet it is retransmitting. 

Certainly using old PSN causes ACK ambiguity. It further causes inaccurate RTT calculation (major) and inability to tell spurious retransmission (minor). I do not think it is a big issue in LOOPS. Timestamp can be carried and echoed back in loops. It solves the major problem of RTT calculation.  At the same time, unlink TCP, LOOPS ingress has no window to maintain. So undo window reduction after spurious retransmission is not even  needed.  

For single retransmission mode, I think it is a good idea. In our experiments,  WAN across countries, most lost packet can be recovered by retransmitting only once. But I suspect if there is any wireless link, single retransmission would not be enough. So probably we need to provide both single retransmission mode and configurable mode (in time or in  number of retransmit times).

Regards,
Yizhou

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Thursday, October 17, 2019 4:07 AM
To: loops@ietf.org
Subject: [LOOPS] Packet sequence numbers

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

-- 
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops