Subject: Re: [quicwg/base-drafts] RESET_STREAM.final_offset is ambiguous (#2262)

From: MikkelFJ <[email-masked]>
Date: Wed, 02 Jan 2019 02:18:18 -0800

Technically QUIC must be able to deliver stream data in-order, but implementations can deliver data out of order, and a sender can data at high offsets way earlier than low offsets (at the risk of being rejected on too many gaps connection error or so).

So, committed bytes or data sent without duplicates does not cover the concept. It is the EndOffset which is of interest.

-- 
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/2262#issuecomment-450827776

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 Jan 2019 15:23:19 -0800

I'm not particularly concerned about making allowances for patchy data, but that would invalidate "total bytes" or anything along those lines.  "Committed bytes" less so, because we might consider a gap to be "committed".

"Used stream data" might work in the sense that it conveys what - of the stream data available - has been used, but I'm not thrilled by it for reasons I can't articulate well.

-- 
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/2262#issuecomment-451016307

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 03 Jan 2019 00:51:46 +0000 (UTC)

What @martinthomson says.

Anyways, I've went with "Final Size", because I did not see any reason to change the word "final." I think that just changing "offset" to "size" fixes the 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/2262#issuecomment-451030499

---

From: Marten Seemann <[email-masked]>
Date: Wed, 02 Jan 2019 21:01:50 -0800

> This is not crisp-clear; it's ambiguous if it means the maximum offset among the bytes that have been sent, or number of bytes that has been sent excluding overlaps (due to retransmissions).

I don’t see a difference here. The offset doesn’t change when you retransmit data.

-- 
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/2262#issuecomment-451056479

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 02 Jan 2019 21:05:16 -0800

@marten-seemann I am not saying that it changes when you retransmit.

What I am calling confusing is that "final offset" sounds like a term referring to the offset of the last octet within a stream. For a stream of 1 byte long, "final offset" could either mean 0 or 1.

-- 
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/2262#issuecomment-451056738

---

From: Marten Seemann <[email-masked]>
Date: Wed, 02 Jan 2019 21:08:19 -0800

Looks like this has nothing to do with retransmissions at all, but just with the definition of "offset". I still like it better than "size" though, because one could reasonably expect the size to change when data is retransmitted, or when sending data with gaps.
Maybe we can define the stream offset as the offset of the next byte that would be sent on the stream would have.

-- 
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/2262#issuecomment-451056963

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 02 Jan 2019 21:17:27 -0800

> Looks like this has nothing to do with retransmissions at all, but just with the definition of "offset".

Correct. That's why I stated "excluding overlaps (due to retransmissions)"; maybe that was confusing though.

> Maybe we can define the stream offset as the offset of the next byte that would be sent on the stream would have.

We can do that. However the downside would be that the difference from the terms we define MAX_DATA and MAX_STREAM_DATA becomes bigger. While MAX_STREAM_DATA can be adjusted that way, I am not sure if we can have a similar definition for MAX_DATA. It should also be noted that MAX_STREAMS uses "stream count"; using "byte count" in the definition of flow control credit is in align of that better than using "offset".

-- 
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/2262#issuecomment-451057671

---

From: janaiyengar <[email-masked]>
Date: Thu, 03 Jan 2019 17:38:01 -0800

@kazuho: Ignore my question on the PR, I understand your ambiguity now. I like "offset" better than "size", but unfortunately, the term does not match the definition. Changing the offset to mean the next byte is viable, but it still isn't intuitive. I think size might be the best we've got.

-- 
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/2262#issuecomment-451332254

---

From: MikkelFJ <[email-masked]>
Date: Fri, 04 Jan 2019 01:33:41 -0800

Regarding size vs offset, consider the hypothetical stream construct where you send every second 256 byte block. If you don't get a STOP_SENDING you continue with the gaps in order after sending the first 128 blocks. This is interleaved image transmission. Now, is the size the number of blocks sendt sent so far, or the end offset.

As @kazuho says, MAX_STREAM_DATA could be adapted either way, while MAX_DATA is more tricky.

But size is not unambiguous either unless you define it cover all unsent gaps as well.

As for interleaving, a better approach is to sent all even lines first, without gaps, then all uneven lines, which avoids the problem.

-- 
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/2262#issuecomment-451395508

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Jan 2019 14:22:14 -0800

I'm not entirely satisfied with the outcome here.  Is this the MAX_STREAM_DATA text that is problematic?

> The MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer of the maximum amount of data that can be sent on a stream.

Because I don't see a problem there.  As a maximum, it naturally doesn't need to concern itself with gaps.  You just can't send the maximum if you leave gaps.

-- 
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/2262#issuecomment-451780573

---

From: MikkelFJ <[email-masked]>
Date: Sun, 06 Jan 2019 14:59:08 -0800

I'd prefer the term `end-offset` because that cannot point to the last byte and it does not say anything about effective payload size, and it works the same for offsets in sparse files.

-- 
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/2262#issuecomment-451783335

---

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Jan 2019 22:37:40 +0000 (UTC)

Closed #2262 via #2285.

-- 
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/2262#event-2061514381