Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FE12DA1A for ; Thu, 10 May 2018 17:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTNdCjEpSIbc for ; Thu, 10 May 2018 17:11:16 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E66612D7E6 for ; Thu, 10 May 2018 17:11:16 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id j143-v6so1270171ybg.2 for ; Thu, 10 May 2018 17:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lYs1jsG5BewT9d5EqDaLkHZrfc/+w2ruQJ+cmVIodpE=; b=BlbWeYgk4kYSvv1VoCCirpSc4nOBh0aslXZZGq/9jQXj3cB05OUnzV5VFgN65z5su1 lOHjc3zCAJOtatBP6tbN80WGnDx9kpUjpBMCuncPpa3l8r9xVWXvYNGThYSultNkXf60 3U4C3OLfXOmuav0Ymo6gcPaRO2jE91B5AYpo5Kngb5dei4Q/PSQ78Rq9VtPreudr00Sw i36Pny49OPoL0PuUWJVz44j6rpDfQTjW72HeTRlJDWFb+5+FMZETHZYLtDlOV1gTFoDf RXIYHLTYRYKr3mvg3kD+vKMoELm6cRJDqbXTNZYHvmI2y1JPnazXupNuutqenYMS3csw fz7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lYs1jsG5BewT9d5EqDaLkHZrfc/+w2ruQJ+cmVIodpE=; b=rcq5yNaKqbEvdyiyrcTUg8OV0gzW8sslXqBguMBkjTzeG1CgpYaWyi5hOQZkq4YkSk AP/CM7gVouAO0WDR2I1q95Ox86YxoagpNreUak5VxNF/nIQVkffh4avHxviyj4ylZ/g3 OTW7VSVjmJVziTbMPvRKroYhjGBQc0uiB7u8jmhRSC6jYStBVod+jyn69P6kR6RkRXp7 z3KUQNigRNHEenQHvmftj4fTDaKTt31GEGzhK6I0aW4ILvrDf5882F1EWdXuz5WsWUwH uJwBuY+RR4B1hrqMzOSplLRJoYao4fJuUYpn0aFVJHarqGofU0xsmbMYjBlDBH3NHak1 30EQ== X-Gm-Message-State: ALKqPwcOBqO3ZD1jakEwYxrbSEZUlXtG+JkMTR1Z2By4YBGe7VYpzj43 jJ3f1eZxCIelMTTKXJqKlw6MiIfpGmOyIA6GdJg6eA== X-Google-Smtp-Source: AB8JxZoxTljnsgkSpyE9ggLVZTE4dIi1sxV8Dwg5aQ4LPmZ276cIwFTzSrLPGEZaKwcf3PeRbHpq2sjiDsQkTwe6qOA= X-Received: by 2002:a25:386:: with SMTP id 128-v6mr50019ybd.241.1525997475328; Thu, 10 May 2018 17:11:15 -0700 (PDT) MIME-Version: 1.0 References: <20180510180509.GA2505@ubuntu-dmitri> <20180510184505.GA23837@ubuntu-dmitri> In-Reply-To: From: Ian Swett Date: Fri, 11 May 2018 00:11:03 +0000 Message-ID: Subject: Re: Why allow empty STREAM frames when offset is zero? To: ilubashe=40akamai.com@dmarc.ietf.org Cc: Roberto Peon , nibanks=40microsoft.com@dmarc.ietf.org, Dmitri Tikhonov , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000007284f5056be2f9ff" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 00:11:18 -0000 --0000000000007284f5056be2f9ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Actually, I=E2=80=99ll 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 t= o > 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 lot= s > of stream data (has not been long enough), but it is very important for t= he > application to know where the sender is in the stream. Of course, there > are workarounds =E2=80=93 you can send a STREAM frame, retransmitting a s= ingle > byte. But it still seems like an unnecessary restriction. > > > > - Igor > > > > > > *From:* Roberto Peon [mailto:fenix@fb.com] > *Sent:* Thursday, May 10, 2018 3:12 PM > *To:* Nick Banks ; Dmitri > Tikhonov ; Mike Bishop > *Cc:* IETF QUIC WG > *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. > > > > -=3DR > > > > > > > > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone > > > > > > -------- Original message -------- > > From: Nick Banks > > Date: 5/10/18 12:02 PM (GMT-08:00) > > To: Dmitri Tikhonov , Mike Bishop < > mbishop@evequefou.be> > > Cc: IETF QUIC WG > > 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 QU= IC > connection, it could be seen as the equivalent of a single TCP connect > event. > > - Nick > > -----Original Message----- > From: QUIC On Behalf Of Dmitri Tikhonov > Sent: Thursday, May 10, 2018 11:45 AM > To: Mike Bishop > Cc: IETF QUIC WG > 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 da= ta > ready to send yet. > > > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org ] On > Behalf Of Dmitri Tikhonov > > Sent: Thursday, May 10, 2018 11:05 AM > > To: IETF QUIC WG > > 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. > > > --0000000000007284f5056be2f9ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would agree that the restriction here seem unnecessary a= nd I tend to think we'd be better off removing it.

On Thu, May 10, 2018 at 5:58 PM Lubashev,= Igor <ilubashe=3D40akama= i.com@dmarc.ietf.org> wrote:

Actually, I=E2=80=99ll take an issue with:=

=C2=A0

[draft-ietf-quic-transport-11] says the following: =C2=A0=C2=A0=C2=A0 A stream frame's Stream Data MUST NOT be empty, unle= ss the offset is
=C2=A0=C2=A0=C2=A0 0 or the FIN bit is set.

Why disallow this?=C2=A0 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.=C2=A0 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.=C2=A0 Of course, there are workaro= unds =E2=80=93 you can send a STREAM frame, retransmitting a single byte.=C2=A0 But it still seems like an unnecessary restriction.

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Roberto Peon [mailto:fenix@fb.com]
Sent: Thursday, May 10, 2018 3:12 PM
To: Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org>; Dmitri= Tikhonov <dtikhonov@litespeedtech.com>; Mike Bishop <mbishop@evequefou.be>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Why allow empty STREAM frames when offset is zero?

=C2=A0

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

=C2=A0

-=3DR

=C2=A0

=C2=A0

=C2=A0

Sent v= ia the Samsung Galaxy S7, an AT&T 4G LTE smartphone

=C2=A0

=C2=A0

-------- Original message --------

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

To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, M= ike Bishop <mb= ishop@evequefou.be>

Cc: IETF QUIC WG <quic@ietf.org>

Subject: RE: Why allow empty STREAM frames when offs= et is zero?

=C2=A0

In WinQuic, the resul= ting frame just results in the NEW_STREAM event to the application layer. T= hey 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 s= ingle QUIC connection, it could be seen as the equivalent of a single TCP c= onnect event.

- Nick

-----Original Message-----
From: QUIC <q= uic-bounces@ietf.org> On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:45 AM
To: Mike Bishop <mbishop@evequefou.be>
Cc: IETF QUIC WG <qui= c@ietf.org>
Subject: Re: Why allow empty STREAM frames when offset is zero?

Is there a real-life use case that is implied here?=C2=A0 I can't see w= hy 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 in= coming 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 oppos= ite direction of a bidirectional stream), but don't actually have data = ready to send yet.
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov
> Sent: Thursday, May 10, 2018 11:05 AM
> To: IETF QUIC WG <quic@ietf.org>
> Subject: Why allow empty STREAM frames when offset is zero?
>
> [draft-ietf-quic-transport-11] says the following:
>
>=C2=A0=C2=A0=C2=A0 A stream frame's Stream Data MUST NOT be empty, = unless the offset is
>=C2=A0=C2=A0=C2=A0 0 or the FIN bit is set.
>
> Why allow empty STREAM frames when the offset is zero?=C2=A0 What is t= he purpose?
>
>=C2=A0=C2=A0 - Dmitri.
>

--0000000000007284f5056be2f9ff--