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

[Martin Thomson <[e-mail]>]

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=
[e-mail]> wrote:

> 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=
[e-mail]> wrote:

>> Actually, I’ll take an issue with:



>> [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 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:[e-mail]]
>> Sent: Thursday, May 10, 2018 3:12 PM
>> To: Nick Banks <nibanks=[e-mail]>; Dmitri Tikhonov
<[e-mail]>; Mike Bishop <[e-mail]>
>> Cc: IETF QUIC WG <[e-mail]>
>> 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







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





>> -------- Original message --------

>> From: Nick Banks <nibanks=[e-mail]>

>> Date: 5/10/18 12:02 PM (GMT-08:00)

>> To: Dmitri Tikhonov <[e-mail]>, Mike Bishop <
[e-mail]>

>> Cc: IETF QUIC WG <[e-mail]>

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



>> 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 <[e-mail]> On Behalf Of Dmitri Tikhonov
>> Sent: Thursday, May 10, 2018 11:45 AM
>> To: Mike Bishop <[e-mail]>
>> Cc: IETF QUIC WG <[e-mail]>
>> 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.

>> On Thu, May 10, 2018 at 06:25:55PM +0000, Mike Bishop 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.
>> >
>> > -----Original Message-----
>> > From: QUIC [mailto:[e-mail]] On Behalf Of Dmitri Tikhonov
>> > Sent: Thursday, May 10, 2018 11:05 AM
>> > To: IETF QUIC WG <[e-mail]>
>> > Subject: Why allow empty STREAM frames when offset is zero?
>> >
>> > [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.
>> >