Re: Decomposing HTTP

Mike,

very nice paper. (Since I am not a native speaker I refrain from commenting the title.:) Some thoughts:

HTTP Hops: what I myself am currently struggling with is the flow control part - when it involves more than one TCP connection. In a reverse proxy scenario, where no disc caching is configured/available, there is always a certain amount of memory and latency and resulting throughput. So, a user experiences response times and throughput as an emerging property of linked transports and their properties. And while HTTPS currently favors seemingly direct connections only, there is almost always a man behind the curtain. Which talks HTTP to someone else. Are there requirements from HTTP on transports regarding this?

Graceful Shutdown/Service Migration: HTTP/1.1 has "Connection: close", HTTP/2 has GOAWAY in order to signal that transport "connections" need to be established anew. This is necessary for reliable request handling in the presence of ever reloading, rebalancing servers. I think a transport needs to provide for this.

Fairness: Optimal use of TCP flow control in HTTP/2, could also make very fat connection desirable (in the absence of packet loss). Which brings up the, I think,  unmentioned feature of fairness. Very fat connection might get penalized by the transport (or get preference), giving such requests lower (or higher) response times.

For example, my HTTP/2 implementation tries to treat all requests equally, no matter what connection they come from, at least when allocating processing resources. But it is a tiny bit more efficient to have some connection stickiness, which then is unfair to others. Is this an issue? I do not know. I do not run large data centers and clusters. But speaking about a hypothetical new transports, it could be a feature worth mentioning.


Cheers, Stefan

> Am 15.03.2016 um 23:48 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> 
> Bringing back this draft so it's alive for BA.  It's pretty much a straight renewal of the 2nd version (with a name change so it shows up in the WG); there was good feedback on the first version, and that has been incorporated.
> 
> This started last summer after discussions at the HTTP Workshop. In our discussions, it became clear that there are actually 2 distinct layers in HTTP 2: the "semantic" layer, which didn't really change much if at all; and the "framing" layer, the mapping between HTTP and TCP, which changed radically. This draft attempts to identify the requirements handled by the framing layer, and looks at how they have been dealt with in various mappings of the HTTP semantic layer to different transport protocols.
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Monday, March 14, 2016 3:31 PM
> To: Mike Bishop <Michael.Bishop@microsoft.com>
> Subject: New Version Notification for draft-bishop-httpbis-decomposing-http-00.txt
> 
> 
> A new version of I-D, draft-bishop-httpbis-decomposing-http-00.txt
> has been successfully submitted by Mike Bishop and posted to the IETF repository.
> 
> Name:		draft-bishop-httpbis-decomposing-http
> Revision:	00
> Title:		Decomposing the Hypertext Transfer Protocol
> Document date:	2016-03-14
> Group:		Individual Submission
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-decomposing-http-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-decomposing-http/
> Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-decomposing-http-00
> 
> 
> Abstract:
>   The Hypertext Transfer Protocol in its various versions combines
>   concepts of both an application and transport-layer protocol.  As
>   this group contemplates employing alternate transport protocols
>   underneath HTTP, this document attempts to delineate the boundaries
>   between these functions to define a shared vocabulary in discussing
>   the revision and/or replacement of one or more of these components.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

Received on Friday, 18 March 2016 16:06:47 UTC