IETF Logo Mail Archive

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

Nick Banks <nibanks@microsoft.com> Thu, 10 May 2018 19:02 UTC

Return-Path: <nibanks@microsoft.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 D14E212EB8D for <quic@ietfa.amsl.com>; Thu, 10 May 2018 12:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 odO_f5XOW1a0 for <quic@ietfa.amsl.com>; Thu, 10 May 2018 12:02:17 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97DB12EBB3 for <quic@ietf.org>; Thu, 10 May 2018 12:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MflOFR89+TFQm5JGmTjZ0CSdt0dKp7e+ZEmO5Y/M5yw=; b=HIPv6M1ZX94yjUo25CNqoI9UO14V8nyAKOFKldhHBFWHjN4L6R5n98evbmOkDqVlhxsOCWGSoSHeM2SBDgXJkUiqSlfqdvKpGiwvX6cMqRZJY63RApo28d1dAjynHsGv4py3KriaLc5POnwDQF0LGc64FTheLDeqO1KyY7Nu34I=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1077.namprd21.prod.outlook.com (52.132.130.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.3; Thu, 10 May 2018 19:02:06 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239%2]) with mapi id 15.20.0776.004; Thu, 10 May 2018 19:02:06 +0000
From: Nick Banks <nibanks@microsoft.com>
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?
Thread-Topic: Why allow empty STREAM frames when offset is zero?
Thread-Index: AQHT6ImMM/Ln2zdjxECadMVu77QIk6QpR5eAgAAFW4CAAAQyAA==
Date: Thu, 10 May 2018 19:02:06 +0000
Message-ID: <DM5PR2101MB090184FC657942BD294E555DB3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
References: <20180510180509.GA2505@ubuntu-dmitri> <SN1PR08MB18543D4C234CC672616E37BFDA980@SN1PR08MB1854.namprd08.prod.outlook.com> <20180510184505.GA23837@ubuntu-dmitri>
In-Reply-To: <20180510184505.GA23837@ubuntu-dmitri>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T19:02:04.8333603Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8::256]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1077; 7:QmBmO81q/5vG/R+iguDObwj7SLLFKqrTdlEhZnQjb109o7jzJo7e/tT2BqaWJWzZkZ1J0QKY6efac3yw8eEPjQQLgiedMaTnkoYhZXvFqFJCA9jzwrXDZRiYCcdKyG3w7Kyt9McHPxM1frVy4ED5Dx+qicEkweYNkpoWUgUhdMWk8sP8xb+miGn2bvj6RvYkZ0+9SnClhfNFHfWcseEFQv+8S21zKEpbKh1mmGObeBWtuakBUQ3xiidp8r3IQYjo; 20:WVAoPW7NIVDi98kkxk6C5KrjbZyXQ8lLTH5zwJppOU4ExcLbSilR19eVDnSnzEpXMomDWLWILuB6puwk57CPi2H4R0KbVN/PrwI5ucXpGSh7qp4cYB0UZ2gq8I7Iu6MSOq3GvRZGenDhfoUeCuENJkX56XMnt2r7Q9qgFvD+WZo=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1077;
x-ms-traffictypediagnostic: DM5PR2101MB1077:
x-microsoft-antispam-prvs: <DM5PR2101MB10772D5A1858863C7E74D5D2B3980@DM5PR2101MB1077.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21532816269658);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR2101MB1077; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1077;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39860400002)(199004)(189003)(13464003)(4326008)(106356001)(97736004)(33656002)(7736002)(68736007)(46003)(55016002)(9686003)(105586002)(8676002)(486006)(6246003)(305945005)(8936002)(110136005)(11346002)(53936002)(8990500004)(81156014)(81166006)(446003)(316002)(6116002)(476003)(5660300001)(14454004)(10290500003)(5250100002)(86612001)(74316002)(186003)(10090500001)(2906002)(3280700002)(25786009)(86362001)(76176011)(6346003)(3660700001)(102836004)(53546011)(7696005)(2900100001)(6506007)(229853002)(478600001)(99286004)(6436002)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1077; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-microsoft-antispam-message-info: EfsOa+ZnxVw4beFoEJcxjJsWj6T7cJwS6U+gpS3qr+sJHMwVyrfgyVEPNSAVFGxvZPJsi8AtJm9/0Tqy/crlgiz2Y1Wclv8vs7g4FlieAjSsyqX2a6rRJ39Eo2oWCAeYVQacqjIAaBLWvv/22bmJcb0FmGgvr5kILBWM8x3Gmq+UqCOHHXvIxYj1aZmWVY4i
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 07185a89-5184-4d13-8501-08d5b6a88619
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 07185a89-5184-4d13-8501-08d5b6a88619
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 19:02:06.3133 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1077
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gd6zsVdCrSGzyTZnWMe80ZGUnO8>
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:02:19 -0000

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.23.0 | Report a Bug | By Email