IETF Logo Mail Archive

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

Roberto Peon <fenix@fb.com> Thu, 10 May 2018 19:12 UTC

Return-Path: <prvs=866817be88=fenix@fb.com>
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 DC06E12DA05 for <quic@ietfa.amsl.com>; Thu, 10 May 2018 12:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ngFiwkB/; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Ac5DbrST
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 XD0hlEKS5f2a for <quic@ietfa.amsl.com>; Thu, 10 May 2018 12:12:07 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB9C1270AB for <quic@ietf.org>; Thu, 10 May 2018 12:12:07 -0700 (PDT)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w4AJBnuh014064; Thu, 10 May 2018 12:12:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=yV9EQ0NeAvKu4iGJyJVGzmiYUXyATC4XSYmP0+wogDU=; b=ngFiwkB/60/9kRIMziMJzeqtjwt0mZ9iD8Mv1jR6oC6bVBkiUfzefEAcew9s3SVJ1mn2 pU46H7DCZWu/l/y7Ft2Ptw8EVFIEtYesfBQ6jcAZEdsUDrTg+5qC3jTBNAtwy26rTFNP sr2O1zawO1mGBwqKctkQuRWKReT/QVBYFMo=
Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2hvtju0cxn-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 May 2018 12:12:00 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.18) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 10 May 2018 12:11:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yV9EQ0NeAvKu4iGJyJVGzmiYUXyATC4XSYmP0+wogDU=; b=Ac5DbrSTF7eunpcS6e8jTQ5NuhRgd3xRytKjwn6WFBUJoJzaASKq+IENYvfBejVkSpZGf6HfYLwfMljBzBLq2iEYbhK+HP+eNXnQi0BTlq5ZHG/jm2TcaV0ot+Et7teP7L8W7OXbYeJuKkVbbgu84MsJ4GVkYMwB+hbXG3ff79c=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0807.namprd15.prod.outlook.com (10.164.171.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Thu, 10 May 2018 19:11:42 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::49b2:cd82:55e8:9da8]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::49b2:cd82:55e8:9da8%14]) with mapi id 15.20.0755.012; Thu, 10 May 2018 19:11:43 +0000
From: Roberto Peon <fenix@fb.com>
To: Nick Banks <nibanks=40microsoft.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?
Thread-Topic: Why allow empty STREAM frames when offset is zero?
Thread-Index: AQHT6ImcXNfNXuzUWkeHTiDTNe07k6QpR5eAgAAFW4CAAATBAIAAArAy
Date: Thu, 10 May 2018 19:11:42 +0000
Message-ID: <BY2PR15MB0775E5FA5E6869C85AB98933CD980@BY2PR15MB0775.namprd15.prod.outlook.com>
References: <20180510180509.GA2505@ubuntu-dmitri> <SN1PR08MB18543D4C234CC672616E37BFDA980@SN1PR08MB1854.namprd08.prod.outlook.com> <20180510184505.GA23837@ubuntu-dmitri>, <DM5PR2101MB090184FC657942BD294E555DB3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
In-Reply-To: <DM5PR2101MB090184FC657942BD294E555DB3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2600:387:6:80d::85]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0807; 7:6Vsj9kdJNYm5oqK3q+4xxUBcNwwex2ugcH1MGVrNsFsml3kZhmdkdv+rZ9f+LsOxmVmXZCjZVzbEJKeOyleawlUhaLtT6IF8S41D7eHwN1lBdUBjk5ZQe76JXKahVrMmwnaBLqpxauNTpbVF8I4Jx70Vh38G2XuYV9920EgQzOvGnFCqmS8+EnWctqsRcTNcQn7eou4bP5dIrlWeD9mToQEQzvyeUYAjt21xcO7l82p3En6c0HYg6yGTJqYBbqLe; 20:cwwJn6TPkUfihgCv0FtoFo5hSU71UtCGfMJyj1oCLPpwjY6BeLXbNZpxgkE8skGraOfg/TcTNjWc6c/nPwRrESM41Xsn1U2Ok/C5k32YGTfFoQQeLd2m7jjOzDA6r/gfwWxstWXowrDhpWGStoKX8np9+Ah2LBJD0NtlqtTgxcs=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0807;
x-ms-traffictypediagnostic: BY2PR15MB0807:
x-microsoft-antispam-prvs: <BY2PR15MB0807996A554179890CDA1C29CD980@BY2PR15MB0807.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21532816269658);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0807; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0807;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(39380400002)(366004)(189003)(199004)(13464003)(106356001)(186003)(53546011)(5660300001)(446003)(11346002)(2906002)(236005)(53936002)(74316002)(110136005)(102836004)(81166006)(105586002)(93886005)(55016002)(476003)(46003)(316002)(3280700002)(97736004)(54896002)(33656002)(8936002)(9686003)(486006)(7696005)(3660700001)(14454004)(8676002)(478600001)(6246003)(5250100002)(6506007)(6436002)(25786009)(229853002)(7736002)(68736007)(99286004)(86362001)(76176011)(6116002)(81156014)(2900100001)(4326008)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0807; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: iIQPOpe/Z1zHuEOZK9pFmSnuL+ftdY+gHywe7dbfCtfCB+2JzbGml8sqpsROsIQWadK7Fro6HYEral8HBRnc3DG72Sq1EjzG4/FHzEu9JtLhnp10jI1IBi4+ngxUaIN4PSeKe055KDEDOXXc8AfhISuBN6UOgBZ6YmNChiyQe8DLNxuCsLgAvauvUvaZskHO
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR15MB0775E5FA5E6869C85AB98933CD980BY2PR15MB0775namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: bd9c4dad-0786-4515-0f88-08d5b6a9ddda
X-MS-Exchange-CrossTenant-Network-Message-Id: bd9c4dad-0786-4515-0f88-08d5b6a9ddda
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 19:11:42.9014 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0807
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-10_06:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/O2LHBo_iQ3vl0d_pGBVS_6CGpwY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 19:12:09 -0000

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=40microsoft.com@dmarc.ietf.org>
Date: 5/10/18 12:02 PM (GMT-08:00)
To: 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?

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 <quic-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 <quic@ietf.org>
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: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:
>
>    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.
>

v2.46.0 | Report a Bug | By Email | System Status