Subject: Re: flow control description in draft

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 16:43:34 +0000

Ya I think the language in the draft could be a bit more clear, will send out a PR soon.

However I have a few more questions that came up:

  1.  Is FIN not subject to flow control? It seems logical to not subject it to flow control, but it's a super weird edge case since FIN has it's own offset :)
  2.  Is it max data or max offset. For example if I send you maxData = 10, can you send until offset 9 or offset 10. I think you mean offset 9.

Subodh

________________________________
From: Ian Swett <[email-masked]>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: flow control description in draft

On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

The flow control language in the draft is a bit confusing right now, and I could use a bit more clarity on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

"A 64-bit unsigned integer indicating the maximum amount of data that can be sent on the entire connection, in units of 1024 octets. That is, the updated connection-level data limit is determined by multiplying the encoded value by 1024."

This seems like it means that flow control is advertised in terms of number of bytes that you can send from that moment.

However from the Flow control section:

"A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to advertise additional credit by sending the absolute byte offset in the connection or stream which it is willing to receive."

I think that we definitely mean offset here in both cases, i.e.

MAX_DATA = sum of max offset of all streams that are allowed

MAX_STREAM_DATA = max offset on a stream

Yes, that's what the spec means.  I thought it was fairly clear, but if you think it's confusing, a PR to improve the wording would be appreciated.

Let's say the conn flow control limit of the receiver is 50. All units in multiples of 1024.

initial state of receiver
stream1 -->  [0, 10]
stream2 -->  [0, 20]

stream3 -->  [0, 20]

So the sender has consumed his entire flow control window. Then the receiver consumes 10 (*1024) bytes from stream1:

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

so now the conn window has 10 (*1024) bytes remaining, what does the receiver send in their update:

MAX_DATA = 10

or

MAX_DATA = 60

I think we mean 60 here. It makes it much easier to maintain the flow control in that case.

Subodh

---

From: Ian Swett <[email-masked]>
Date: Mon, 14 Aug 2017 12:49:28 -0400

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <[email-masked]> wrote:

>    1. Is FIN not subject to flow control? It seems logical to not subject
>    it to flow control, but it's a super weird edge case since FIN has it's own
>    offset :)
>
>
A fin is not subject to flow control.  I guess I think of it taking up no
space, so it doesn't seem like a problem, but I can see your point.

>
>    1. Is it max data or max offset. For example if I send you maxData =
>    10, can you send until offset 9 or offset 10. I think you mean offset 9.
>
>
> Good point, that seems worth clarifying.

> Subodh
>
> ------------------------------
> *From:* Ian Swett <[email-masked]>
> *Sent:* Friday, July 28, 2017 9:57:23 AM
> *To:* Subodh Iyengar
> *Cc:* [email-masked]
> *Subject:* Re: flow control description in draft
>
>
>
> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar <[email-masked]> wrote:
>
>> The flow control language in the draft is a bit confusing right now, and
>> I could use a bit more clarity on the intention
>>
>> "A 64-bit unsigned integer indicating the maximum amount of data that can
>> be sent on the entire connection, in units of 1024 octets. That is, the
>> updated connection-level data limit is determined by multiplying the
>> encoded value by 1024."
>>
>> This seems like it means that flow control is advertised in terms of
>> number of bytes that you can send from that moment.
>>
>
>> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to
>> advertise additional credit by sending the absolute byte offset in the
>> connection or stream which it is willing to receive."
>>
>> Yes, that's what the spec means.  I thought it was fairly clear, but if
> you think it's confusing, a PR to improve the wording would be appreciated.
>
>
>> So the sender has consumed his entire flow control window. Then the
>> receiver consumes 10 (*1024) bytes from stream1:
>>
>> stream1 ---> (10, 10)
>>
>> stream2 ---> [0, 20]
>>
>> stream3 ---> [0, 20]
>>
>>

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 19:17:59 +0000

Ya the complexity of not having FIN as subject to flow control is that the stream frame scheduler would have special logic for processing FINs while checking whether it has flow control. This wouldn't be an editorial issue though and is more of a design issue. I've put up a PR for the design change, if people don't like the change I can put up a PR for only the editorial change instead keeping the current semantics:

https://github.com/quicwg/base-drafts/pull/730

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Ian Swett <[email-masked]>
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: flow control description in draft

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

A fin is not subject to flow control.  I guess I think of it taking up no space, so it doesn't seem like a problem, but I can see your point.

  1.  Is it max data or max offset. For example if I send you maxData = 10, can you send until offset 9 or offset 10. I think you mean offset 9.

Subodh

________________________________
From: Ian Swett <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: flow control description in draft

stream3 -->  [0, 20]

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

MAX_DATA = 10

or

MAX_DATA = 60

Subodh

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Aug 2017 19:31:41 +0000

Like Ian, I don't see this as an issue - assuming everything is rationalized around offsets, the check is always whether (current offset) + (payload length) <= (allowed offset).  Even if (current offset) == (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will still be true.

From: QUIC [mailto:[email-masked]] On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <[email-masked]>
Cc: [email-masked]
Subject: Re: flow control description in draft

https://github.com/quicwg/base-drafts/pull/730<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F730&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cde116c93a6054ba1f03908d4e3493c55%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636383351072157121&sdata=03FmH5HWuka0Etbp8ATWC5DrSNx8Q9Bi8M2RUWDBb7c%3D&reserved=0>

Subodh

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Ian Swett <[email-masked]<mailto:[email-masked]>>

Subodh

stream3 -->  [0, 20]

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

MAX_DATA = 10

or

MAX_DATA = 60

Subodh

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 19:49:57 +0000

@Mike ya another issue I brought up is that it's actually not rationalized around offsets right now, the current formulation is around maximum data which is what raised the question of FINs. The PR changes the formulation to be around offsets. This is discussed in the PR summary. Let me know what you think.

Subodh

________________________________
From: Mike Bishop <[email-masked]>
Sent: Monday, August 14, 2017 12:31:41 PM
To: Subodh Iyengar; Ian Swett
Cc: [email-masked]
Subject: RE: flow control description in draft

Like Ian, I don’t see this as an issue – assuming everything is rationalized around offsets, the check is always whether (current offset) + (payload length) <= (allowed offset).  Even if (current offset) == (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will still be true.

https://github.com/quicwg/base-drafts/pull/730<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fquicwg-252Fbase-2Ddrafts-252Fpull-252F730-26data-3D02-257C01-257Cmichael.bishop-2540microsoft.com-257Cde116c93a6054ba1f03908d4e3493c55-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636383351072157121-26sdata-3D03FmH5HWuka0Etbp8ATWC5DrSNx8Q9Bi8M2RUWDBb7c-253D-26reserved-3D0&d=DwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Z0rsCsduYJuOuUkzymXZCJcC3MNcJCDkYqMlP_dayWc&s=GxyIGY3n2bVv1Kc1V4_taeVQyyRu-P_4YbY7CP3Kty4&e=>

Subodh

Subodh

stream3 -->  [0, 20]

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

MAX_DATA = 10

or

MAX_DATA = 60

Subodh

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 15:23:43 -0700

Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN
does not need be included in flow control accounting. The only reason it
consumes an offset is the case where it is sent on an empty STREAM frame.
But this does matter for flow control since as Ian pointed out, this byte
does not consume any buffer space. I'll look at the PR.

On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar <[email-masked]> wrote:

> @Mike ya another issue I brought up is that it's actually not rationalized
> around offsets right now, the current formulation is around maximum data
> which is what raised the question of FINs. The PR changes the formulation
> to be around offsets. This is discussed in the PR summary. Let me know what
> you think.
>
>
> Subodh
> *From:* Mike Bishop <[email-masked]>
> *Sent:* Monday, August 14, 2017 12:31:41 PM
> *To:* Subodh Iyengar; Ian Swett
> *Cc:* [email-masked]
> *Subject:* RE: flow control description in draft
>
>
> Like Ian, I don’t see this as an issue – assuming everything is
> rationalized around offsets, the check is always whether (current offset) +
> (payload length) <= (allowed offset).  Even if (current offset) == (allowed
> offset), a STREAM frame that contains only a FIN will have a payload length
> of zero, so this will still be true.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Subodh Iyengar
> *Sent:* Monday, August 14, 2017 12:18 PM
> *To:* Ian Swett <[email-masked]>
> *Cc:* [email-masked]
> Ya the complexity of not having FIN as subject to flow control is that the
> stream frame scheduler would have special logic for processing FINs while
> checking whether it has flow control. This wouldn't be an editorial issue
> though and is more of a design issue. I've put up a PR for the design
> change, if people don't like the change I can put up a PR for only the
> editorial change instead keeping the current semantics:
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fquicwg-252Fbase-2Ddrafts-252Fpull-252F730-26data-3D02-257C01-257Cmichael.bishop-2540microsoft.com-257Cde116c93a6054ba1f03908d4e3493c55-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636383351072157121-26sdata-3D03FmH5HWuka0Etbp8ATWC5DrSNx8Q9Bi8M2RUWDBb7c-253D-26reserved-3D0&d=DwMFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Z0rsCsduYJuOuUkzymXZCJcC3MNcJCDkYqMlP_dayWc&s=GxyIGY3n2bVv1Kc1V4_taeVQyyRu-P_4YbY7CP3Kty4&e=>
>
>
>
> Subodh
> *From:* QUIC <[email-masked]> on behalf of Ian Swett <
> [email-masked]>
> *Sent:* Monday, August 14, 2017 9:49:28 AM
> *To:* Subodh Iyengar
> *Cc:* [email-masked]
> The flow control language in the draft is a bit confusing right now, and I
> could use a bit more clarity on the intention
>

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 23:16:20 +0000

Ya I think my confusion initially is that in some parts of the document it says that the max data represents the offset, however in other parts it refers to it as the max data you can send. These have subtly different meanings. I chose to interpret the max data as offsets rather than amount of data to be sent, and that's why I arrived at the conclusion that I would have to account for the FIN separately and sent out a PR to represent all quantities as offsets.

Of course, as Mike and Ian point out, this could also work with the current formulation of maximum data. We could keep it as it is and have a editorial PR to modify the language of the flow control section instead to call this out more.

For clarity we should either choose amount of data or offset all throughout. To me, it seemed more intuitive to send offsets if limits are being sent on offsets, but I'm happy with either approach.

Subodh

________________________________
From: Jana Iyengar <[email-masked]>
Sent: Monday, August 14, 2017 3:23:43 PM
To: Subodh Iyengar
Cc: Mike Bishop; Ian Swett; [email-masked]
Subject: Re: flow control description in draft

Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN does not need be included in flow control accounting. The only reason it consumes an offset is the case where it is sent on an empty STREAM frame. But this does matter for flow control since as Ian pointed out, this byte does not consume any buffer space. I'll look at the PR.

On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

Subodh

From: Mike Bishop <[email-masked]<mailto:[email-masked]>>

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: flow control description in draft

Subodh

Subodh

stream3 -->  [0, 20]

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

MAX_DATA = 10

or

MAX_DATA = 60

Subodh

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Aug 2017 09:40:39 +1000

I don't think that a characterisation of FIN of "consuming an offset"
is correct.  The frame includes an offset, which is the point
*between* octets on the stream.  The first octet in the frame (if
present) is immediately after that gap.

Think of it like this:

Octets:   ,_0_,_1_,_2_,_3_,_4_,

The offset is at the comma, not the numeral.  FIN makes the comma a period.

On 15 August 2017 at 08:23, Jana Iyengar <[email-masked]> wrote:
> Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN does
> not need be included in flow control accounting. The only reason it consumes
> an offset is the case where it is sent on an empty STREAM frame. But this
> does matter for flow control since as Ian pointed out, this byte does not
> consume any buffer space. I'll look at the PR.
>
>> which is what raised the question of FINs. The PR changes the formulation to
>> be around offsets. This is discussed in the PR summary. Let me know what you
>> think.
>>
>>
>> Subodh
>>
>> Is FIN not subject to flow control? It seems logical to not subject it to
>> flow control, but it's a super weird edge case since FIN has it's own offset
>> :)
>>
>>
>>
>> Is it max data or max offset. For example if I send you maxData = 10, can
>> you send until offset 9 or offset 10. I think you mean offset 9.
>>
>>
>>
>> updated connection-level data limit is determined by multiplying the encoded
>> value by 1024."
>>

---

From: Ian Swett <[email-masked]>
Date: Mon, 14 Aug 2017 19:46:23 -0400

> The offset is at the comma, not the numeral.  FIN makes the comma a period.
Agreed.

> does
> >> Ya I think the language in the draft could be a bit more clear, will
> send
> >> out a PR soon.
> >>
> >>
> >>
> encoded
> >> Let's say the conn flow control limit of the receiver is 50. All units
> in
> >> multiples of 1024.
> >>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 14 Aug 2017 17:11:20 -0700

> The offset is at the comma, not the numeral.  FIN makes the comma a period.

I'm not sure I am following. An offset is on a STREAM frame, and it
indicates the offset of the data in the frame. In a pure FIN frame, it
still indicates something. Whether you consider this to be an offset
consumed or not, it still indicates something. The offset indicated on the
STREAM frame is processed per flow-control. The question that the draft is
unclear on is whether the offset received on a pure FIN frame is to be
considered per flow control or not. I don't think it needs to, but that
needs to be articulated in the draft.

In your example, a pure FIN frame sent at the end of 5 bytes of data will
carry the offset 6. That is now an offset that cannot be used for anything
else but that FIN. Which, in my understanding, means that the offset is
"consumed" by the FIN.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Aug 2017 10:54:00 +1000

On 15 August 2017 at 10:11, Jana Iyengar <[email-masked]> wrote:
> indicates the offset of the data in the frame. In a pure FIN frame, it still
> indicates something. Whether you consider this to be an offset consumed or
> not, it still indicates something. The offset indicated on the STREAM frame
> is processed per flow-control. The question that the draft is unclear on is
> whether the offset received on a pure FIN frame is to be considered per flow
> control or not. I don't think it needs to, but that needs to be articulated
> in the draft.

I thought that conclusion was already implicit in the draft.  I'm
happy to have it made explicit.

> else but that FIN. Which, in my understanding, means that the offset is

The FIN has an offset of 5.  5 octets of data each start at offsets 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM frame
has an offset of 5.

I have no idea why an offset would be consumed by declaring the stream
complete.  What has changed is that you now know how long the
stream/message is.

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.cplusplus.com/doc/tutorial/arrays/

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Aug 2017 20:06:28 -0500

> http://www.cplusplus.com/doc/tutorial/arrays/

I had mentioned it offlist, but since summoned, I will note that I was
thinking of a description like
https://blog.nelhage.com/2015/08/indices-point-between-elements/ , which
has some advantages in reintroducing symmetry as to which pointer values
are defined to compute/dereference, forward/reverse iteration, etc.

-Ben

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 15 Aug 2017 02:56:27 +0000

Ya I think Jana probably just made a typo in saying 6, it would clearly be 5.

I see your point here though, that is only data has offsets, FIN just communicates how much data was sent.
Even though this value is encoded in an offset field, it's not really an offset. I think this point could be better illustrated with

some sort of editorial change which changes the name of final Offset to be called Written Bytes.

I've updated the PR to reflect some of this discussion. The PR should now be editorial.

Subodh

________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; [email-masked]
Subject: Re: flow control description in draft

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.cplusplus.com/doc/tutorial/arrays/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cplusplus.com_doc_tutorial_arrays_&d=DwMCaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=pfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU&s=IATo-4cXErWzgjq4ek9UJSoH31kZQ0SveGIkB6nVySs&e=>

I had mentioned it offlist, but since summoned, I will note that I was thinking of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/<https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.nelhage.com_2015_08_indices-2Dpoint-2Dbetween-2Delements_&d=DwMCaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=pfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU&s=yllN6u9Xvgb7libPi2Az-MYW6aztWj1YtrCVnXy4WQ4&e=> , which has some advantages in reintroducing symmetry as to which pointer values are defined to compute/dereference, forward/reverse iteration, etc.

-Ben

---

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Aug 2017 23:08:20 +0000

Per discussion on the editor's call today:  If I say you're allowed to send up to 10, that means you MUST NOT send anything in position 10.  Otherwise stated, both FINs and flow control limits reference the line between positions and are [0,N), as in Ben's excellent link below.

As a result, we need to update the text to talk not so much about offsets in flow control as total amount of data, since that appears to be clearer.

Ben, thanks for clarifying our thinking here.

From: Subodh Iyengar [mailto:[email-masked]]
Sent: Monday, August 14, 2017 7:56 PM
To: Benjamin Kaduk <[email-masked]>; Martin Thomson <[email-masked]>; Jana Iyengar <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Ian Swett <[email-masked]>; [email-masked]
Subject: Re: flow control description in draft

You don't often get email from [email-masked]<mailto:[email-masked]>. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>

Feedback<http://aka.ms/SafetyTipsFeedback>

Subodh

________________________________
From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; [email-masked]<mailto:[email-masked]>
Subject: Re: flow control description in draft

has an offset of 5.

stream/message is.

http://www.cplusplus.com/doc/tutorial/arrays/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.cplusplus.com_doc_tutorial_arrays_%26d%3DDwMCaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3Dh3Ju9EBS7mHtwg-wAyN7fQ%26m%3DpfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU%26s%3DIATo-4cXErWzgjq4ek9UJSoH31kZQ0SveGIkB6nVySs%26e%3D&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cb965292f0d294d158c0a08d4e3893efb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636383626015080722&sdata=M588zvUDlH%2B%2FpSDBbNpGOcjGQUI1Ha7s0lO%2BnVB6Q4k%3D&reserved=0>

I had mentioned it offlist, but since summoned, I will note that I was thinking of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__blog.nelhage.com_2015_08_indices-2Dpoint-2Dbetween-2Delements_%26d%3DDwMCaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3Dh3Ju9EBS7mHtwg-wAyN7fQ%26m%3DpfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU%26s%3DyllN6u9Xvgb7libPi2Az-MYW6aztWj1YtrCVnXy4WQ4%26e%3D&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cb965292f0d294d158c0a08d4e3893efb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636383626015080722&sdata=dLp%2BJuEZSd%2Bhl7XZIBAUCjCugpq6HZ2Hw5i7QyBDYO4%3D&reserved=0> , which has some advantages in reintroducing symmetry as to which pointer values are defined to compute/dereference, forward/reverse iteration, etc.

-Ben

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 15 Aug 2017 16:13:46 -0700

Yes, Martin I know what arrays are. BTW, the reference you sent for C
arrays is incorrect, here's
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf> a better one
:-)
Thanks, Ben, for the blog post: I like that articulation.

My apologies: I was legitimately confused because TCP consumes a sequence
number for both the SYN and the FIN, and I keep reverting to old behavior.
TCP consumes a number for reliability purposes (so that a receiver can ACK
these bits), but QUIC does not need to do this on stream FINs and stream
offsets, since these aren't about reliability, they're about
receive-ordering.

I agree that FIN does not need to consume an offset, so there needs to be
no provision in flow control for it. Given that, I'll look at the PR to see
if it helps clarify this point further.

On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar <[email-masked]> wrote:

> Even though this value is encoded in an offset field, it's not really an
> offset. I think this point could be better illustrated with
>
> *From:* Benjamin Kaduk <[email-masked]>
> *Sent:* Monday, August 14, 2017 6:06:28 PM
> *To:* Martin Thomson; Jana Iyengar
> *Cc:* Mike Bishop; Ian Swett; Subodh Iyengar; [email-masked]
> haven't read up on these before, here's a primer:http://www.cplusplus.com/doc/tutorial/arrays/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cplusplus.com_doc_tutorial_arrays_&d=DwMCaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=pfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU&s=IATo-4cXErWzgjq4ek9UJSoH31kZQ0SveGIkB6nVySs&e=>
>
>
> thinking of a description like https://blog.nelhage.com/2015/
> 08/indices-point-between-elements/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.nelhage.com_2015_08_indices-2Dpoint-2Dbetween-2Delements_&d=DwMCaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=pfZ-RV4YdZsOse1c08-35p3MAoF_CYnUjntvmU9DjOU&s=yllN6u9Xvgb7libPi2Az-MYW6aztWj1YtrCVnXy4WQ4&e=>
> , which has some advantages in reintroducing symmetry as to which pointer
> values are defined to compute/dereference, forward/reverse iteration, etc.
>
> -Ben
>

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 16 Aug 2017 02:52:01 +0000

Thanks everyone for the discussion. I'm going to abandon my PR and wait for the changes that Mike mentioned.

Subodh

________________________________
From: Jana Iyengar <[email-masked]>
Sent: Tuesday, August 15, 2017 4:13:46 PM
To: Subodh Iyengar
Cc: Benjamin Kaduk; Martin Thomson; Mike Bishop; Ian Swett; [email-masked]
Subject: Re: flow control description in draft

Yes, Martin I know what arrays are. BTW, the reference you sent for C arrays is incorrect, here's<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_jtc1_sc22_wg14_www_docs_n1570.pdf&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=KoswUBQUdu9TOCK3bgpH9dLAb0AA1Pr--qpVkudr1LA&s=vizYH5TNdpuUdOc6SNIlgVIW_YBa1mw9ukd7EMDSJPI&e=> a better one :-)
Thanks, Ben, for the blog post: I like that articulation.

My apologies: I was legitimately confused because TCP consumes a sequence number for both the SYN and the FIN, and I keep reverting to old behavior. TCP consumes a number for reliability purposes (so that a receiver can ACK these bits), but QUIC does not need to do this on stream FINs and stream offsets, since these aren't about reliability, they're about receive-ordering.

I agree that FIN does not need to consume an offset, so there needs to be no provision in flow control for it. Given that, I'll look at the PR to see if it helps clarify this point further.

On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

Subodh

-Ben