Subject: Why allow empty STREAM frames when offset is zero?

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 10 May 2018 14:05:25 -0400

[draft-ietf-quic-transport-11] says the following:

   A stream frame's Stream Data MUST NOT be empty, unless the offset is
   0 or the FIN bit is set.

Why allow empty STREAM frames when the offset is zero?  What is the
purpose?

  - Dmitri.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 18:25:55 +0000

If you want to open a stream (e.g. permit data to be sent in the opposite direction of a bidirectional stream), but don't actually have data ready to send yet.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:05 AM
To: IETF QUIC WG <[email-masked]>
Subject: Why allow empty STREAM frames when offset is zero?

Why allow empty STREAM frames when the offset is zero?  What is the purpose?

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 10 May 2018 14:45:05 -0400

Is there a real-life use case that is implied here?  I can't see why it
would be useful.

On the other hand, it creates an odd situation for an implementation:
a frame has arrived, yet the higher layer cannot read from it yet, so
an incoming stream is unreadable.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 10 May 2018 21:01:25 +0200

maybe its the only way to get more stream id flow control credits :)

On Thu, May 10, 2018 at 8:45 PM, Dmitri Tikhonov <
[email-masked]> wrote:

> > If you want to open a stream (e.g. permit data to be sent in the
> opposite direction of a bidirectional stream), but don't actually have data
> ready to send yet.
> >

---

From: Nick Banks <[email-masked]>
Date: Thu, 10 May 2018 19:02:06 +0000

In WinQuic, the resulting frame just results in the NEW_STREAM event to the application layer. They can start reading from it, but we just won't have anything to read yet. That NEW_STREAM event can be used for a number of things. If you are moving from multiple TCP connections to a single QUIC connection, it could be seen as the equivalent of a single TCP connect event.

- Nick

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:45 AM
To: Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Why allow empty STREAM frames when offset is zero?

Is there a real-life use case that is implied here?  I can't see why it would be useful.

On the other hand, it creates an odd situation for an implementation:
a frame has arrived, yet the higher layer cannot read from it yet, so an incoming stream is unreadable.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 10 May 2018 15:10:46 -0400

On Thu, May 10, 2018 at 07:02:06PM +0000, Nick Banks wrote:
> If you are moving from multiple TCP connections to a single QUIC
> connection, it could be seen as the equivalent of a single TCP
> connect event.

Hmm!  This is an interesting way to look at it.

  - Dmitri.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 10 May 2018 19:11:42 +0000

It can be used to establish the mapping of the stream (src-conn-id:streamid <-> dst-conn-id:streamid) through the stack of proxies, etc, especially for usecases where there is an early response.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Nick Banks <nibanks=[email-masked]>
Date: 5/10/18 12:02 PM (GMT-08:00)
To: Dmitri Tikhonov <[email-masked]>, Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: RE: Why allow empty STREAM frames when offset is zero?

- Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 10 May 2018 21:58:22 +0000

Actually, I'll take an issue with:

Why disallow this?  This may be a signal to the receiver about where in the stream the sender is, even if the sender does not have any new data to send.  This signal may be useful in cases of packet loss, when the sender is not ready to declare a packet with stream data lost and retransmit lots of stream data (has not been long enough), but it is very important for the application to know where the sender is in the stream.  Of course, there are workarounds - you can send a STREAM frame, retransmitting a single byte.  But it still seems like an unnecessary restriction.

  *   Igor

From: Roberto Peon [mailto:[email-masked]]
Sent: Thursday, May 10, 2018 3:12 PM
To: Nick Banks <nibanks=[email-masked]>; Dmitri Tikhonov <[email-masked]>; Mike Bishop <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Why allow empty STREAM frames when offset is zero?

-=R

-------- Original message --------
From: Nick Banks <nibanks=[email-masked]<mailto:nibanks=[email-masked]>>
Date: 5/10/18 12:02 PM (GMT-08:00)
To: Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>>, Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: Why allow empty STREAM frames when offset is zero?

- Nick

-----Original Message-----
From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:45 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Why allow empty STREAM frames when offset is zero?

On Thu, May 10, 2018 at 06:25:55PM +0000, Mike Bishop wrote:
> To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>

---

From: Ian Swett <[email-masked]>
Date: Fri, 11 May 2018 00:11:03 +0000

I would agree that the restriction here seem unnecessary and I tend to
think we'd be better off removing it.

On Thu, May 10, 2018 at 5:58 PM Lubashev, Igor <ilubashe=
[email-masked]> wrote:

> Actually, I’ll take an issue with:
>
>
>
> Why disallow this?  This may be a signal to the receiver about where in
> the stream the sender is, even if the sender does not have any new data to
> send.  This signal may be useful in cases of packet loss, when the sender
> is not ready to declare a packet with stream data lost and retransmit lots
> of stream data (has not been long enough), but it is very important for the
> application to know where the sender is in the stream.  Of course, there
> are workarounds – you can send a STREAM frame, retransmitting a single
> byte.  But it still seems like an unnecessary restriction.
>
>
>
>    - Igor
>
>
>
>
>
> *From:* Roberto Peon [mailto:[email-masked]]
> *Sent:* Thursday, May 10, 2018 3:12 PM
> *To:* Nick Banks <nibanks=[email-masked]>; Dmitri
> Tikhonov <[email-masked]>; Mike Bishop <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>
> *Subject:* Re: Why allow empty STREAM frames when offset is zero?
>
>
>
> It can be used to establish the mapping of the stream
> (src-conn-id:streamid <-> dst-conn-id:streamid) through the stack of
> proxies, etc, especially for usecases where there is an early response.
>
>
>
> -=R
>
>
>
>
>
>
>
> In WinQuic, the resulting frame just results in the NEW_STREAM event to
> the application layer. They can start reading from it, but we just won't
> have anything to read yet. That NEW_STREAM event can be used for a number
> of things. If you are moving from multiple TCP connections to a single QUIC
> connection, it could be seen as the equivalent of a single TCP connect
> event.
>
> - Nick
>
> > From: QUIC [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Dmitri Tikhonov

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 May 2018 10:37:23 +1000

That's possible, if someone wants to open a PR.

To be clear, I don't think that there is a valid use case for an empty
STREAM frame (other than at the start or end) that isn't satisfied better
by other frames.  But we're not necessarily in the business of policing
these things and allowing empty STREAM frames is actually easier than
creating the exclusions.

Here's a use case: steganography.  A covert channel to the peer that won't
manifest as observable activity outside of the QUIC stack.  An empty STREAM
frame can carry a surprising amount of entropy if you are clever.

We would then put empty STREAM frames in the same bucket as other frames
that could be pointless and wasteful when used excessively.  There's
already a bunch of those.
On Fri, May 11, 2018 at 10:11 AM Ian Swett <ianswett=

>> Igor

>> To: Nick Banks <nibanks=[email-masked]>; Dmitri Tikhonov
<[email-masked]>; Mike Bishop <[email-masked]>

would be useful.

purpose?

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 11 May 2018 01:27:48 +0000

Done.  https://github.com/quicwg/base-drafts/pull/1350

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, May 10, 2018 8:37 PM
To: Ian Swett <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; Nick Banks <[email-masked]>; Mike Bishop <[email-masked]>; Roberto Peon <[email-masked]>; QUIC WG <[email-masked]>; Dmitri Tikhonov <[email-masked]>
Subject: Re: Why allow empty STREAM frames when offset is zero?

To be clear, I don't think that there is a valid use case for an empty STREAM frame (other than at the start or end) that isn't satisfied better by other frames.  But we're not necessarily in the business of policing these things and allowing empty STREAM frames is actually easier than creating the exclusions.

Here's a use case: steganography.  A covert channel to the peer that won't manifest as observable activity outside of the QUIC stack.  An empty STREAM frame can carry a surprising amount of entropy if you are clever.

We would then put empty STREAM frames in the same bucket as other frames that could be pointless and wasteful when used excessively.  There's already a bunch of those.

> On Thu, May 10, 2018 at 5:58 PM Lubashev, Igor <ilubashe= [email-masked]> wrote:

>> Why disallow this?  This may be a signal to the receiver about where 
>> in the stream the sender is, even if the sender does not have any new data to send.  This signal may be useful in cases of packet loss, when the sender is not ready to declare a packet with stream data lost and retransmit lots of stream data (has not been long enough), but it is very important for the application to know where the sender is in the stream.  Of course, there are workarounds – you can send a STREAM frame, retransmitting a single byte.  But it still seems like an unnecessary restriction.