Re: draft-ietf-quic-http-29, "1.1. Prior versions of HTTP"

Paul Vixie <paul@redbarn.org> Fri, 12 June 2020 18:01 UTC

Return-Path: <paul@redbarn.org>
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 AC8A63A07C4 for <quic@ietfa.amsl.com>; Fri, 12 Jun 2020 11:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Wyp0cMNjYy6G for <quic@ietfa.amsl.com>; Fri, 12 Jun 2020 11:01:25 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFC43A07BA for <quic@ietf.org>; Fri, 12 Jun 2020 11:01:14 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 35047B07D1; Fri, 12 Jun 2020 18:01:14 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Julian Reschke <julian.reschke@gmx.de>, Robin MARX <robin.marx@uhasselt.be>, quic@ietf.org
Cc: IETF QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>
Subject: Re: draft-ietf-quic-http-29, "1.1. Prior versions of HTTP"
Date: Fri, 12 Jun 2020 18:01:13 +0000
Message-ID: <1846406.p7HaY3GM0x@linux-9daj>
Organization: none
In-Reply-To: <CH2PR22MB2086EED7405119874EA54374DA810@CH2PR22MB2086.namprd22.prod.outlook.com>
References: <8c747b59-1672-4ccb-dfce-0914e74c504f@gmx.de> <672c5568-e137-0105-b043-baba983a289e@gmx.de> <CH2PR22MB2086EED7405119874EA54374DA810@CH2PR22MB2086.namprd22.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yDDGj9Bmep8BbQsEc0JYlmvJEHg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Jun 2020 18:01:28 -0000

On Friday, 12 June 2020 15:55:36 UTC Mike Bishop wrote:
> Robin has almost the intended reading.  One request/response at a time, in
> each direction.  So while you might send several requests in sequence
> before getting any responses back, each direction is always either in the
> middle of exactly one message, or between messages.

the terminology here is easily confusable. in HTTP/1.1, a greedy responder can 
parse pipelined requests and start the work associated with each. however, the 
answers have to come back in order. this "head of line blocking" imposes 
response serialization, and HTTP/3 avoids this.

one way to word this is to call out serialization of both requests and 
responses, and ordering of responses, as limits of HTTP/1.1 that HTTP/3 is 
designed to overcome. wording like "at the same time" is less clear.

-- 
Paul