Re: [LOOPS] Packet sequence numbers

["Morten V. Pedersen" <[e-mail]>]

Hi all,
I'm not an expert on QUIC or such, but what was the motivation for 
continuously increasing sequence numbers there. I imagine they had some 
good reasons to go down that path.

 From a FEC and re-transmission standpoint continuously increasing 
sequence numbers yields simpler implementations from my point of view.

It is relatively easy for the FEC implementation to estimate the packet 
loss, and for a pure re-transmission scheme detection of "holes" is 
trivial without worrying about what data the packet carried i.e. if it 
was payload data or a re-transmission in itself. It can just report back 
and say I did not get packet X whatever it was.

All the best,
Morten


On 10/21/19 10:45 PM, Carsten Bormann wrote:
>> Even though I originally suggested the QUIC method of continuously increasing sequence numbers, I think this assessment of the trade-offs is very good, and now I tend to agree that, for LOOPS, repeating sequence numbers would be better.
> I think that this conclusion is a good basis for continuing the work.
> I made the necessary changes (I think) in https://github.com/loops-wg/gen-info/commit/2dd7634
>
> I also added some text about mitigating ACK ambiguity, which is facilitated if the ingress never sets “ACK desired” on a retransmission.
>
> There is currently no detailed text on how to decide to retransmit.  The current spec is mute (a.k.a. “flexible”) on the implementation strategy.  For hole-based retransmission triggering, re-using the PSD needs to include a hold-off for packets that have recently been retransmitted so another copy of block 2 information that just confirms the existing hole doesn’t trigger another retransmission.  For a time-based retransmission scheme (as in RACK), retransmission would simply move forward the packet into the then appropriate slot.
>
>> +1 on the need for more-than-once, for wireless links.
> Right.  I think that single retransmission is a nice implementation strategy for some applications, so we should continue to pay attention that we don’t inadvertently make it harder to do than it is now.
>
> Grüße, Carsten
>