Subject: [quicwg/base-drafts] Transport: GAP limitation in ACK Frame (#613)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Jun 2017 01:46:28 -0700

In draft-ietf-quic-transport-03, Section 8.2.1:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              First ACK Block Length (8/16/32/48)            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  [Gap 1 (8)]  |       [ACK Block 1 Length (8/16/32/48)]     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  [Gap 2 (8)]  |       [ACK Block 2 Length (8/16/32/48)]     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  [Gap N (8)]  |       [ACK Block N Length (8/16/32/48)]     ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Gap To Next Block (opt, repeated):  An unsigned number specifying the
      number of contiguous missing packets from the end of the previous
      ACK block to the start of the next.  Repeated "Num Blocks" times.

So, to my understanding the gap counter is fixed to 8 bits, and thus have a maximum GAP distance of 255. Considering that packet numbers are not required to be a continuous number, nor have a limit that the largest gap is less than 255, I wonder how one handles situations where the GAP between received packet numbers are larger than 255? Do one use multiple ACK frames, where each acking the sub-set of packet numbers that are separeted by GAPs larger than 255?

-- 
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/613

---

From: Patrick McManus <[email-masked]>
Date: Thu, 08 Jun 2017 01:51:56 -0700

yes, new ack frame.

-- 
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/613#issuecomment-307041388

---

From: Marten Seemann <[email-masked]>
Date: Thu, 08 Jun 2017 01:53:36 -0700

You don't need a new frame. You can just set the length to 0 if you need to encode a gap larger than 255.

-- 
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/613#issuecomment-307041810

---

From: ianswett <[email-masked]>
Date: Thu, 08 Jun 2017 01:55:14 -0700

Marten is correct, and at some point, as Patrick said, a new ACK frame is necessary.

I could add text to clarify this?

-- 
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/613#issuecomment-307042207

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Jun 2017 02:00:22 -0700

So this needs clarification in the text on how you handle the case I brought up. I also see a relation to this issue  #423. So please add text on this. 

-- 
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/613#issuecomment-307043406

---

From: ianswett <[email-masked]>
Date: Tue, 20 Jun 2017 18:31:50 -0700

I sent out a PR for clarifying the use of 0 length ack ranges, but I think it's best to resolve the multiple ack frames issue on #423

-- 
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/613#issuecomment-309937071

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 26 Jun 2017 21:54:20 -0700

Is this the same (or worse) for timestamps in the ACK frame?

The current text is pretty vague, but seems to say that the _Delta Largest Acked 1..N_ value is always at most 255 from the _Largest Acknowledged_ (not the previous delta).

So... timestamps can go backwards (or rather, packet numbers can go backwards inside the timestamp section), and you can't timestamp packets with much larger numbers.

Even if the _Delta N_ was changed to be relative to _Delta N-1_, you still couldn't set the _Time Since Previous_ to 0 to skip over gaps>255, since the text says that the delta is used to calculate the number of the actual packet being timestamped.

-- 
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/613#issuecomment-311252752

---

From: ianswett <[email-masked]>
Date: Tue, 27 Jun 2017 07:45:59 -0700

Timestamps are only sent once, so assuming there isn't a large amount of reordering or loss, up the the 255th most recent is more than sufficient.

But yes, if you're commonly experiencing loss and reordering >255 packets, you won't get timestamps.  But that is extraordinarily rare in my experience, and since timestamps are best effort, one should use them as an enhancement to congestion control, not the sole input.

-- 
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/613#issuecomment-311381263