Subject: [quicwg/base-drafts] Subsequent Delta LA values (#307)

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Feb 2017 17:07:47 -0800

The definition of "Delta Last Acked" is the same for all of the timestamp entries.  This implies that every packet number in the timestamp block is expressed relative to the "Last Acked".  That would make it impossible to provide timestamps for packets more than 255 packet numbers behind the last acknowledged packet and multiple ACK frames would be needed to do that.

I don't think that's right, but that subsequent deltas apply to the last timestamp.  That is:
```diff
  packet_number[0] = last_acknowledged - delta_last[0]
- packet_number[n] = last_acknowledged - delta_last[n]
+ packet_number[n] = last_acknowledged - sum(1, n, delta_last[i])
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/307

---

From: ianswett <[email-masked]>
Date: Wed, 15 Feb 2017 08:10:07 -0800

Actually, that's how it works today, and I didn't particularly consider it a problem, since TCP and QUIC by default ack every two packets.  One can imagine schemes that ack less often, and I've implemented two of them, but even then, acking over 200 packets at once would be a bit crazy.

There was a choice between ordering the timestamps by time or by packet number.  I ended up choosing time.

Given timestamps are not retransmitted, they're best effort feedback, and the loss of a small number of timestamps cannot be a critical issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/307#issuecomment-280054569