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

["Lubashev, Igor" <[e-mail]>]

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

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

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.