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

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

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]<mailto:nibanks=[e-mail]>>
Date: 5/10/18 12:02 PM (GMT-08:00)
To: Dmitri Tikhonov <[e-mail]<mailto:[e-mail]>>, Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:45 AM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[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]<mailto:[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.
>