Re: Pipeline hinting revisited

On Fri, Aug 12, 2011 at 5:48 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 12/08/11 19:05, Yngve N. Pettersen wrote:
>>
>> On Fri, 12 Aug 2011 08:20:13 +0200, Amos Jeffries wrote:
>>>
>>> I was just thinking the 100-continue infrastructure built up over the
>>> last few years with some success could be leveraged here. "Expect:
>>> pipeline" and a 1xx status to indicate explicit support.
>>
>> It sounds to me like you are assuming that a server that understand the
>> Expect header, but does not understand the "pipeline" expectation, will
>> just return a normal 200 OK response. Unfortunately, that is incorrect:
>> Such servers will return a 417 "Expectation failed" error code.
>>
>> I have seen servers send that code for the 100-continue expectation.
>
> I'm assuming the client which chose to send it does support it. Same
> assumptions in use for rolling out 100-continue.
>
> pipeline as a per-hop feature.
>
> 1XX - the hop supports. Explicit support. Worst case of no change in overall
> connection lag.
>
> 417 - the hop or something downstream refuses support. Explicit failure.
> More importantly _fast_ failure.
>
> 200 (or others) is a possibility. Indicating risk.
>  - From hops which do not support Expect:
>  - from servers which do accept pipeline but choose not to send 1XX.
>  - from hops which strip the 1XX sent by a server.

Two of the three cases seem to have undesirable performance characteristics:

1XX: total elapsed time is 1xRTT greater than optimal.

417: total elapsed time is 1xRTT greater than if the client hadn't
tried to pipeline at all.

200 or other: assuming the client responds by accepting the response
and disabling pipelining on the connection, the total elapsed time is
the same as it would have been if the client hadn't tried to pipeline
at all.

Ideally I'd like to avoid an extra round trip because queue depths of
only 2-4 requests on a connection are common, at least in the data set
I've studied.  Adding in a synchronous negotiation step before the
first request would eliminate much of the benefit that pipelining
would otherwise provide for these request sequences.

Here's another idea, although it's one that I expect will be
controversial: how about adding a new method?

PGET /resource HTTP/1.1
Host: www.example.com

If the server supports pipelining, it treats the request as a GET.  If
not, it replies with a 400 or 405.  (The rationale for using a new
method name instead of a new request header is to make sure the
request triggers an error response from any existing server or
intermediary implementation that doesn't recognize the new pipelining
mechanism.)

If the client receives a 400 or 405, it retries the request as a GET.
If the client receives any other response status, it pipelines
subsequent requests on that connection.  Those subsequent requests may
be sent as either GET or PGET; either will work.

If the server is a proxy that understands this new method, the
implementer can decide whether to send the request upstream to the
next hop as a PGET or convert it to a GET.

Since this approach does add an extra round trip whenever the client
sends a PGET request to a server that doesn't support it, it might
best be used in combination with an out-of-band hinting mechanism.

What do you folks think?

Thanks,
-Brian

Received on Friday, 12 August 2011 20:51:40 UTC