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

[Ian Swett <[e-mail]>]

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] <[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.
> >
>