Subject: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00

From: Salvatore Loreto <[email-masked]>
Date: Wed, 9 Mar 2011 13:37:13 +0200

(as individual)

Martin, Greg and I have submitted the following draft:
http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt

The draft only defines HTTP headers that can be (re)used for discovery 
idle time to use in
both LongPolling/Comet and WebSocket connection lifetime management 
(keep alive process).

Note, the draft does not discuss the actual WebSocket keep alive process;
and this thread is only to discuss the mechanism for discovery idle time.

Comments and opinions on the draft are very welcome and appreciate.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

-------- Original Message --------
Subject: 	New Version Notification for draft-thomson-hybi-http-timeout-00
Date: 	Mon, 7 Mar 2011 00:09:52 +0100
From: 	IETF I-D Submission Tool <[email-masked]>
To: 	[email-masked] <[email-masked]>
CC: 	Salvatore Loreto <[email-masked]>, 
"[email-masked]" <[email-masked]>

A new version of I-D, draft-thomson-hybi-http-timeout-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository.

Filename:	 draft-thomson-hybi-http-timeout
Revision:	 00
Title:		 Hypertext Transfer Protocol (HTTP) Timeouts
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
A Request-Timeout header is defined for Hypertext Transfer Protocol
(HTTP).  This end-to-end header informs an origin server and any
intermediaries of the maximum time that a client will await a
response to its request.  A server can use this header to ensure that
a timely response is generated.  This also identifies requests as
being potentially long-lived, and allows for better resource
allocation for these requests.

A Connection-Timeout header is defined for HTTP.  This hop-by-hop
header informs the entity at the other end of a connection of the
maximum time that an idle connection is kept open.  This header
improves reliability by providing better information about the idle
connection management policy of HTTP hosts.

The IETF Secretariat.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Mar 2011 09:39:25 -0800

Hey,

A couple of thoughts --

I regularly am asked by devs for something like Request-Timeout, usually for enforcement on an intermediary, rather than the origin, but it's applicable there too.

I always resist it, because there's a race condition between the client's declared request time and its enforcement (as you know it). It's better to just close the connection and enforce the timeout where it's declared; no matter how clearly you document that this is just advisory, many developers will look at request-timeout and immediately use it in place of a client-side timeout. 

Do you have use cases for Request-Timeout that aren't covered by a client-side timeout?

Regarding Connection-Timeout - I still think a simple indication that it's a long-lived request is more useful (and truthful), but if you are going to go down this road, you'll need to define 'idle' more carefully. 

For example, Squid had the concept of a read timeout <http://www.squid-cache.org/Versions/v2/2.HEAD/cfgman/read_timeout.html>, which applies to connections with an outstanding request on them, but it also has a persistent request timeout <http://www.squid-cache.org/Versions/v2/2.HEAD/cfgman/persistent_request_timeout.html> which applies to those that don't. How do they interact with Connection-TImeout?

Cheers,	

On 09/03/2011, at 3:37 AM, Salvatore Loreto wrote:

> The draft only defines HTTP headers that can be (re)used for discovery idle time to use in
> both LongPolling/Comet and WebSocket connection lifetime management (keep alive process).
> 
> CC:	Salvatore Loreto <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 18 Mar 2011 12:14:46 +0800

Hi Mark,

Thanks for putting thought into this.  This is exactly the sort of feedback we need.

On 2011-03-11 at 04:39:25, Mark Nottingham wrote:
> Hey,
> 
> A couple of thoughts --
> 
> I regularly am asked by devs for something like Request-Timeout, 
> usually for enforcement on an intermediary, rather than the origin, 
> but it's applicable there too.
> 
> I always resist it, because there's a race condition between the 
> client's declared request time and its enforcement (as you know it).
> It's better to just close the connection and enforce the timeout where 
> it's declared; no matter how clearly you document that this is just 
> advisory, many developers will look at request-timeout and immediately 
> use it in place of a client-side timeout.
> 

Since you ask, yes :)

In a lot of scenarios, a simple client-side connection drop is going to be sufficient.  That's true for the case where responses arrive atomically - the classic comet use case.

It is a little inefficient to drop the connection.  After all, it's not always the case that the client really needs to drop the connection, maybe they just wanted to ask about something else instead.  But that's not the case that motivated this for me.  I could see why you might reject a request for a new header on those grounds alone - politeness alone is insufficient justification.

In the business that I work in - location - knowing how long you have to answer up front is considered quite valuable.  A GPS receiver takes a certain amount of time to start producing anything at all, and it's a pretty power hungry beast.  You don't even bother trying the GPS receiver unless you have some indication from your client that they are willing to wait for the response.  If they don't have the time, you can choose a quicker method, like round-trip timing or *waves hands* myriad other options.  But each of those location determination methods have their own limitations.

Thus, it's not a case of just waiting until an atomic event occurs.  It's about setting down the request constraints up front.

We can (and already do) set those constraints in requests in other ways.  Currently, the best option we have is POST bodies, but you'll appreciate that this doesn't interact well with other HTTP features.
 
> Regarding Connection-Timeout - I still think a simple indication that 
> it's a long-lived request is more useful (and truthful), but 

I was thinking that Request-Timeout would provide that bit of information indicating the request being long-lived - after all, a connection header isn't going to make it onto the next hop.  If that single bit is all you are looking for, of course...

Connection-Timeout / Keep-Alive still has value for a client who wants to reuse a connection.  Even without long-polling, they can use that information to determine whether or not to open a new connection for their POST request.

> if you 
> are going to go down this road, you'll need to define 'idle' more 
> carefully.

I'll admit that the definition of 'idle' is a little casual, but is there anything fundamentally wrong with the idea that it is
 a) subjective
 b) based on either sending or receiving of data
 c) probably ignorant of buffering and any fancy TCP layer stuff (Nagle's algorithm, etc, though that's hardly measurable at a granularity of seconds)

> For example, Squid had the concept of a read timeout 
> <http://www.squid- 
> cache.org/Versions/v2/2.HEAD/cfgman/read_timeout.html>, which applies 
> to connections with an outstanding request on them, but it also has a 
> persistent request timeout <http://www.squid- 
> cache.org/Versions/v2/2.HEAD/cfgman/persistent_request_timeout.html>
> which applies to those that don't. How do they interact with 
> Connection-TImeout?

The intent is to combine the two.  Each time that you send or receive data, you reset the time.  Given the configuration for Squid, you would have to report the lower of these two.

Note that with the default Squid configuration, you could report a 15min time to servers and a 2min time to clients.  That doesn't work so well for a persistent server connection, since it doesn't appear like the read timeout pays any attention to the fact that you are using the connection to send.  For instance, if you receive a new request just before the end of a 15 min read idle, you might time out at 15 min despite the fact that the connection might have been OK.

(That's just me reading a lot into those descriptions alone, I didn't look at the code...)

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Mar 2011 13:21:24 +1100

On 18/03/2011, at 3:14 PM, Thomson, Martin wrote:
> It is a little inefficient to drop the connection.  After all, it's not always the case that the client really needs to drop the connection, maybe they just wanted to ask about something else instead.  

I don't see how request-timeout helps here; you seem to be saying that the client can assume that it's OK after request-timeout seconds to submit a new request on the connection, and assume that the old request has been "cancelled" server-side. That fundamentally doesn't work.

Its true that there's ambiguity between purposeful connection drop and accidental (e.g., network-related) drop. However, it seems to me that using timeouts is a very bad way to detect this. Why not send a request explicitly saying that you're dropping the connection instead? E.g.,

OPTIONS * HTTP/1.1
Expect: im-outta-here-and-i-mean-it

That's just one way, there are lots of others (e.g., a chunk-extension).

> Thus, it's not a case of just waiting until an atomic event occurs.  It's about setting down the request constraints up front.

Ah -- OK, that's an interesting use case. I didn't get that from the draft. 

This smells a little bit like the Prefer header:
  http://tools.ietf.org/html/draft-snell-http-prefer-02

Did you consider using something like that? E.g., 
  Prefer: response-fast

Where the parameters of 'response-fast' is specific to the resource.

As you can probably guess, I'm suggesting this because I'm concerned that 95% of people who want to use something like Request-Timeout won't have such a subtle use case in mind.

> c) probably ignorant of buffering and any fancy TCP layer stuff (Nagle's algorithm, etc, though that's hardly measurable at a granularity of seconds)

It depends very much on how it's used by receiving software. Your points only emphasise how little real information there is in the number that's getting transmitted...

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Mar 2011 12:21:11 +0800

On 2011-03-21 at 13:21:24, Mark Nottingham wrote:
> > It is a little inefficient to drop the connection.  After all, it's
> not always the case that the client really needs to drop the 
> connection, maybe they just wanted to ask about something else instead.
> 
> I don't see how request-timeout helps here; you seem to be saying that 
> the client can assume that it's OK after request-timeout seconds to 
> submit a new request on the connection, and assume that the old 
> request has been "cancelled" server-side. That fundamentally doesn't work.

That's not the intent.  I assume that if the server knows request-timeout, then they are able to send an error response at that time, making the connection available.  Obviously, if the client sends another request after that time, they are effectively pipelining...with all that entails.
 
> Its true that there's ambiguity between purposeful connection drop and 
> accidental (e.g., network-related) drop. However, it seems to me that 
> using timeouts is a very bad way to detect this. 

The draft talks about that.  There will always be a need to handle lost connections.  Timeouts can't help, and we wouldn't pretend that they would.

> Why not send a 
> request explicitly saying that you're dropping the connection instead? 
> E.g.,
> 
> OPTIONS * HTTP/1.1

I don't see how that would help at all.

> > In the business that I work in - location - knowing how long you 
> > have
> to answer up front is considered quite valuable.  A GPS receiver takes 
> a certain amount of time to start producing anything at all, and it's 
> a pretty power hungry beast.  You don't even bother trying the GPS 
> receiver unless you have some indication from your client that they 
> are willing to wait for the response.  If they don't have the time, 
> you can choose a quicker method, like round-trip timing or *waves 
> hands* myriad other options.  But each of those location determination 
> methods have their own limitations.
> >
> > Thus, it's not a case of just waiting until an atomic event occurs.
> It's about setting down the request constraints up front.
> 

Interesting thought, but ultimately it ends up with the same semantics of request-timeout:
   Prefer: response-within=10

A single bit doesn't quite suffice for this use case.  While there is some value in being able to choose between the slowest and the fastest response, that precludes a range of in-between options.

> As you can probably guess, I'm suggesting this because I'm concerned 
> that 95% of people who want to use something like Request-Timeout 
> won't have such a subtle use case in mind.

And if that's the case, that's a good reason not to define a new header and look for other options (like Prefer).

> > I'll admit that the definition of 'idle' is a little casual, but is 
> > there anything fundamentally wrong with the idea that it is
> > a) subjective
> > c) probably ignorant of buffering and any fancy TCP layer stuff 
> > (Nagle's algorithm, etc, though that's hardly measurable at a 
> > granularity of seconds)
> 
> It depends very much on how it's used by receiving software. Your 
> points only emphasise how little real information there is in the 
> number that's getting transmitted...

It is a promise to a peer that they wont close the connection until they think the connection is idle (as above) for the specified time, exceptional circumstances excepted.

For instance, a client that sees a value of 120 might choose to reuse a connection that is (subjectively) idle for 90s.  Whether they also reuse the connection at 100, 110 and 119 is up to implementation/local configuration/other unspecified heuristics.

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Mar 2011 12:18:50 +1100

> That's not the intent.  I assume that if the server knows request-timeout, then they are able to send an error response at that time, making the connection available.  Obviously, if the client send…

OK. That needs to be specified, then (or at least illustrated).

> I don't see how that would help at all.

I thought you were concerned about differentiating between intentional and unintentional client connection drops. If not, no worries.

> A single bit doesn't quite suffice for this use case.  While there is some value in being able to choose between the slowest and the fastest response, that precludes a range of in-between options.

response-within seems much more reasonable. 

Cheers,