Subject: [quicwg/base-drafts] MAX_STREAM_DATA discrepancy (#1744)

From: Vidhi Goel <[email-masked]>
Date: Thu, 13 Sep 2018 18:02:48 +0000 (UTC)

In the transport draft, under Frames section, max_stream_data refers to.
"A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of octets";

whereas under Flow Control section, it refers to max absolute offset, quoted

"MAX_STREAM_DATA frames send the maximum absolute byte offset of a stream. A receiver MAY advertise a larger offset at any point by sending MAX_DATA or MAX_STREAM_DATA frames. A receiver cannot renege on an advertisement; that is, once a receiver advertises an offset, advertising a smaller offset has no effect. A sender MUST therefore ignore any MAX_DATA or MAX_STREAM_DATA frames that do not increase flow control limits."

This discrepancy can cause the implementations to differ as max. amount of data is treated differently than max absolute offset. Can we clarify this in the draft?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Sep 2018 21:11:15 -0700

There is no discrepancy.

The potential for discrepancy might come from the possibility that data can be sparse.  That is, not all data up to the maximum offset is sent.  More likely, it is lost and therefore not received.  For instance, if I am set a limit of 10 and only send octets 5 through 9, then I have sent 5 octets.  But I can still send 0 through 4 if I choose.  So it is still possible to send 10 octets.

However, when calculating flow control, it's important that we don't count the total octets that are sent or received.  We have to account for the maximum in all cases, because there might be some disagreement between sender and receiver about whether a specific octet were exchanged.

The text in [the description of the frame](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#frame-max-stream-data) is a high-level description of the purpose of the frame.  It elides that detail intentionally to keep the text simple.  Its purpose is to aid comprehension, not provide detail.  As it is still essentially correct, I'm not inclined to change anything here.

-- 
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/1744#issuecomment-421225344

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 14 Sep 2018 10:49:34 -0700

Using the same example, initial limit = 10. Sender sends 10 octets and receive ACK for 0 through 4. Now, from the sender's perspective, can it still send 10 octets (ie. from 5 to 14) - no. It can only send up to the offset advertised 10, effectively - 5 octets. 

-- 
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/1744#issuecomment-421434939

---

From: MikkelFJ <[email-masked]>
Date: Fri, 14 Sep 2018 10:58:00 -0700

It doesn't matter if data is ack'ed or not and to the stream it doesn't matter if data is retransmitted. What matters is largest offset, exactly because it is not sensitive to race conditions. The stream limit has to do with the application more than flow control at the transport level.

Transmission and retransmission does count against global data limits because it is placed in a new packet in a new frame, and this is senstive to flow control at the transport level.

-- 
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/1744#issuecomment-421437251

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 14 Sep 2018 11:06:10 -0700

I agree with the idea of using largest offset. What I am trying to say is max_stream_data in the draft refers to maximum amount of data that can be sent (under frames section) which might be confused as sliding window mechanism; and it is clearly not that.

-- 
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/1744#issuecomment-421439501

---

From: MikkelFJ <[email-masked]>
Date: Fri, 14 Sep 2018 11:11:55 -0700

it could be formulated slightly more precise but the paragraph below the headline description says:

"When counting data toward this limit, an endpoint accounts for the largest received offset of data that is sent or received on the stream. "

-- 
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/1744#issuecomment-421440963

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 14 Sep 2018 11:19:19 -0700

I am hoping that readers would pay attention to the following paragraph and associated reference in flow control section.

-- 
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/1744#issuecomment-421442967

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 14 Sep 2018 20:35:09 +0000 (UTC)

Closed #1744.

-- 
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/1744#event-1846989771