Re: I-D Action:draft-nottingham-http-pipeline-00.txt

Hi Patrick,

Thanks for the feedback. A few (delayed) responses inline:

On 24/08/2010, at 6:31 AM, Patrick McManus wrote:
> 
> I think it is helpful to break #1 down into two categories (and maybe
> you meant this and my reading of the document would just benefit from
> clarification):
> 
>  - 1a] server closes connection without processing (some portion of)
> pipeline. This is a minor performance nit when the request could have
> been served on a parallel connection instead of being pipelined. But the
> loose constraints about when servers can close connections make it
> difficult to determine whether this is a pipelining failure or just a
> semi-random and expected event.
> 
>  - 1b] server silently discards pipelined requests but remains open for
> requests on persistent connection. That's really ugly because it either
> turns into a big timeout or #2 if another request is sent that the
> server perceives as non-pipelined. (and of course what the ua perceives
> as pipelined may not look that way to the server).

Yes. If you'd like to co-author, BTW, I'm sure that can be arranged...


> My first question is do we have any information on the relative
> importance of each? I must say that I have not personally witnessed an
> instance of #1b, #2 or #3 in several years (and I say that as anecdote,
> not as an assertion that they aren't running wild in someone else's view
> of the Internet - so the question is sincere).. while #1a and #4 have
> been various-levels of disasters for me when I have tried to introduce
> pipelining into an intermediary.

Good question. While we could run some studies against top100 Web sites, etc., it would IMO be more useful if we could get some stats from implementations that do use pipelining; namely, Opera and Mozilla (when enabled). 

I wonder how feasible it would be to have them collect stats (e.g., # of reqs successfully pipelined, average pipeline length, pipeline errors broken down by type) and have the user opt into them being sent to a server.


> I do share the expressed concern about making the correlation ID be the
> same URL used by the UA. I appreciate the fact that it can just be
> stored as part of cached headers, but too much rewriting, routing, et al
> goes on in today's Web to expect that to be consistently matched (or
> even translated to be the same easily). More importantly, I fear that we
> would accidentally be introducing false-positives into the system as
> each endpoint viewed the naming differently and through errors even when
> pipelining was working. It's not clear to me assoc-req is less fragile
> than anonymous pipelining which it is trying to help.

False positives are a concern, but at worst pipelining wouldn't work in those cases; i.e., the Web site still would, so it would be a "soft" failure.

What I'm trying to do is create some aids to pipelining deployment that might even be temporary (i.e., only in use for a few years); they'll help get us to a place where pipelining is more common. As such, false positives aren't as bad as the current situation, IMO.


> In contrast, the checksum scheme is also cache friendly, isn't dependent
> on naming, seems to accomplish all of what assoc-req does(*), and has
> the advantage of already being well defined. There is a minor
> computational cost, to be sure, but I think its lack of deployment is
> more related to the lack of perceived benefit than anything else. If
> developers buy into a benefit for assoc-req then why wouldn't they be
> convinced of the same logic supporting md-5? And md-5 doesn't need a new
> standards document.

When you say 'the checksum scheme' do you mean Content-MD5 and similar approaches? 

If so, I don't think it provides everything that assoc-req does; it doesn't tie the response to its associated request.

If not, could you please explain? 


> Also along those lines, md-5 plays well with proxies. Assoc-req makes my
> head hurt - the draft says proxies should never generate assoc-req (and
> I get why), but pipelining is certainly not necessarily an end-to-end
> property in practice.. some hops might want to initiate it by
> multiplexing different tcp sessions together (crazy in today's
> conditions, but if they had reason to believe it was safe to do so it
> makes a lot of sense for something like a server side content
> accelerator to do).. and some hops commonly undo pipelines without
> breaking interop simply by behaving in a store and forward fashion...
> even if a hop didn't want to initiate a pipeline it might want to deploy
> a "safe pipeline" spec in order to allow the safe enablement of
> pipelining in legacy browsers as a service to its users. 

Why does Assoc-Req make that hard?


> (*)assoc-req could of course also be used in an out-of-order scheme but
> we seem to be in agreement that is out of scope for http/1.*

Absolutely. 


> Especially #4 - a primary case is simply the filtering out of things
> like comet long polls as well as large and slow documents. To a
> reasonable extent content (and javascript) authors can figure some of
> that stuff out and label it as you suggest, but I am troubled by the gap
> between the protocol and whatever markup the attribute lives in. I don't
> have a suggestion at my fingertips but it seems that if the hint lived
> within the protocol somehow it would be much more versatile and helpful,
> right?  The timeout of 1b could also be shortened significantly in the
> presence of some kind of hinting.

Yes. One of the things I want to add to a future revision are ways for XmlHttpRequest authors to hint pipelining use. 


> I'm pessimistic that attribute level meta data can help much with
> scenario #1a.. #1a seems more driven by the implementation and
> configuration of the server itself rather than the application data that
> it serves. The latter often doesn't know much about the former. The
> server could hint at the protocol layer about its implementation, but
> that doesn't portend to be very satisfying. I wish I was making a more
> constructive statement here. In some ways this is the least significant
> but most intractable problem.

Agreed. The hinting is really for #4.

Cheers,

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

Received on Tuesday, 31 August 2010 05:54:00 UTC