Subject: Empty Stream with FIN

From: Subodh Iyengar <[email-masked]>
Date: Tue, 7 Mar 2017 03:22:23 +0000

It seems strange that for an empty stream frame with a FIN bit, the sender needs to use the last offset + 1. Is there an existential reason for using offset + 1 during the FIN with empty stream case? It seems easier to be able to deal with the FIN bit on a stream with data, and a stream without data uniformly.

I also noticed https://github.com/quicwg/base-drafts/issues/240 which proposes getting rid of FINs completely.

Subodh

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Mar 2017 14:31:08 +1100

On 7 March 2017 at 14:22, Subodh Iyengar <[email-masked]> wrote:
> It seems strange that for an empty stream frame with a FIN bit, the sender
> needs to use the last offset + 1. Is there an existential reason for using
> offset + 1 during the FIN with empty stream case? It seems easier to be able
> to deal with the FIN bit on a stream with data, and a stream without data
> uniformly.

You always send the offset of the last byte + 1.

If you send 1 byte, the offset of that byte is 0.  However, if you
send a RST_STREAM, then you signal "1".  When you send the next set of
bytes, the offset of that byte is 1.  That's the case even when you
are sending zero bytes (which is what you send when sending a FIN.

> proposes getting rid of FINs completely.

Not completely, just where they are always empty (the client side of
the stream in server push).

---

From: Mike Bishop <[email-masked]>
Date: Tue, 7 Mar 2017 03:32:51 +0000

Well, alternately stated, the last offset is the next byte you would have sent.  For an empty stream, that would be zero, which seems logical.

Sent from my Windows 10 phone

From: Subodh Iyengar<mailto:[email-masked]>
Sent: Monday, March 6, 2017 7:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Empty Stream with FIN

Subodh

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 7 Mar 2017 03:45:08 +0000

> Well, alternately stated, the last offset is the next byte you would have sent.  For an empty stream, that would be zero, which seems logical.

Ya I'm not suggesting that it doesn't make logical sense, and it is definitely one way to do it.

What was strange to me was that with this construction, a receiver would need to handle the case of a FIN with an empty stream separately from the case of a FIN on a stream. An alternate similarly logical construction would be to set the offset to be the position of the FIN in the stream which seems more consistent with RST_STREAM. This has the added benefit of simplifying an implementation which could deal with it in the same code path as getting a FIN on a stream with data.

Thanks for the clarification @martin

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Mike Bishop <[email-masked]>
Sent: Monday, March 6, 2017 7:32:51 PM
To: Subodh Iyengar; [email-masked]
Subject: RE: Empty Stream with FIN

Subodh

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Mar 2017 14:53:28 +1100

On 7 March 2017 at 14:45, Subodh Iyengar <[email-masked]> wrote:
> What was strange to me was that with this construction, a receiver would
> need to handle the case of a FIN with an empty stream separately from the
> case of a FIN on a stream. An alternate similarly logical construction would
> be to set the offset to be the position of the FIN in the stream which seems
> more consistent with RST_STREAM. This has the added benefit of simplifying
> an implementation which could deal with it in the same code path as getting
> a FIN on a stream with data.

I think that the reason is that you can know where the end of a stream
is by the same calculation every time: <offset> + <number of octets in
this frame>.  If this frame is empty, then this produces the answer in
the draft.  Assuming that the logical position of the FIN is always on
(or before) the next octet.

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 7 Mar 2017 04:13:33 +0000

Sounds good. Putting it that way does keep it consistent across the empty FIN and the non-empty stream case.

Thanks,

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Monday, March 6, 2017 7:53:28 PM
To: Subodh Iyengar
Cc: Mike Bishop; [email-masked]
Subject: Re: Empty Stream with FIN