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

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jun 2020 13:48:42 +0200

> HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages. While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and motivates tolerance of variant behavior. Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints.

Isn't that a bit misleading, as at least in theory HTTP/1.1 supports
pipelining?

BEst regards, Julian

---

From: Robin MARX <[email-masked]>
Date: Fri, 12 Jun 2020 15:20:19 +0200

Hello Julian,

To me, the crux is in the "at a time", which I feel makes the statement
correct.
Of course the nuances might not be clear for less experienced readers, but
I don't feel the H3 text should explain the details of this.

With best regards,
Robin

On Fri, 12 Jun 2020 at 13:49, Julian Reschke <[email-masked]> wrote:

> > HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited text
> fields to convey HTTP messages. While these exchanges are human-readable,
> using whitespace for message formatting leads to parsing complexity and
> motivates tolerance of variant behavior. Because each connection can
> transfer only a single HTTP request or response at a time in each
> direction, multiple parallel TCP connections are often used, reducing the
> ability of the congestion controller to effectively manage traffic between
> endpoints.
>

-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jun 2020 16:21:33 +0200

On 12.06.2020 15:20, Robin MARX wrote:
 > ...

Not really; if the server is not broken I can send multiple GET requests
without having read any response yet.

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Fri, 12 Jun 2020 15:55:36 +0000

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.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Julian Reschke
Sent: Friday, June 12, 2020 10:22 AM
To: Robin MARX <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: draft-ietf-quic-http-29, "1.1. Prior versions of HTTP"

On 12.06.2020 15:20, Robin MARX wrote:
> Hello Julian,
>
> To me, the crux is in the "at a time", which I feel makes the 
> statement correct.
 > ...

Not really; if the server is not broken I can send multiple GET requests without having read any response yet.

Best regards, Julian

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Jun 2020 18:01:13 +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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 19 Jun 2020 09:19:48 +1000

My .02 -

I think we need to balance between being correct and over-complicating the text here. In *theory*, Julian is correct; in wide practice, pipelining isn't used because of the limitations it has, as well as implementation / interop issues.

How about something like:

"Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..."

?

Cheers,

> On 12 Jun 2020, at 9:48 pm, Julian Reschke <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Jun 2020 05:03:57 +0200

> "Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..."

SGTM.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 19 Jun 2020 10:33:19 -0700

> On Jun 18, 2020, at 4:19 PM, Mark Nottingham <[email-masked]> wrote:
> 
> My .02 -
> 

No, it isn't used by browsers because they aren't aware of the purpose
for each connection and request. API clients almost always use pipelines.

> "Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..."

Why don't you just say

  "Because HTTP/1.x does not include a multiplexing layer, multiple
   TCP connections are often used to service requests in parallel.
   However, that has a negative impact on congestion control and network
   efficiency, since TCP does not share congestion control across multiple
   connections."

because those are the actual technical limitations.

....Roy

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 25 Jun 2020 18:48:37 -0700

I've filed https://github.com/quicwg/base-drafts/issues/3790 for this
editorial issue.

On Fri, Jun 19, 2020 at 10:33 AM Roy T. Fielding <[email-masked]> wrote:

> > I think we need to balance between being correct and over-complicating
> the text here. In *theory*, Julian is correct; in wide practice, pipelining
> isn't used because of the limitations it has, as well as implementation /
> interop issues.
>
> > "Because of limitations in how HTTP exchanges are mapped onto TCP
> connections in HTTP/1.1, multiple parallel connections are often used..."
>
> Why don't you just say
>
> .....Roy