Re: [LOOPS] Packet sequence numbers

Hi all,

It is my understanding (but I might be wrong!) that the motivation was just to avoid retransmission ambiguity when there’s no need to have it - continuously growing sequence numbers make things simpler, and given the length of the field in QUIC, they would support very long transfers, so the disadvantage is minuscule. And, indeed, it generally makes things simpler.

One of the disadvantages mentioned here was related to monitoring tools - that doesn’t apply to QUIC either because its sequence numbers are encrypted.

Cheers,
Michael

> On Oct 22, 2019, at 8:18 AM, Morten V. Pedersen <morten@steinwurf.com> wrote:
> 
> 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
>> 
> 
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops