Subject: [hybi] Questions about http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-03

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 10 Nov 2012 18:07:02 -0800

There were some updates on
https://code.google.com/p/chromium/issues/detail?id=131960, so this I-D
recently came to my attention. I have a number of questions about it. Let
me know if I should be asking somewhere else. Btw, please keep me cc'd on
replies since I'm not subscribed to this mailing list.

Just to doublecheck, are the motivations for this header primarily
described in Section 1.1? I'm reading:
"""

   Management of idle HTTP connections has an impact on long-lived
   communications between hosts.  Hosts are able to close idle
   connections in order to reduce resource consumption.

   Many clients choose not to send non-idempotent requests on idle
   connections.  If the intermediary or server holding the other end of
   the connection chooses to close the connection while a non-idempotent
   request is in transit, the client has no way to tell if the request
   has succeeded.  For this reason, many clients establish a new
   connection for every non-idempotent request.  This is inefficient if
   the existing connection is a usable connection: establishing a new
   connection adds significantly to the latency of the request.

   Connection resources can be more efficiently used when an idle
   connection timeout is known.  A client that only periodically sends
   request can learn about the possibility of a connection timeout and
   can act to create a new connection for requests or send requests that
   keep the connection from timing out.  Alternatively, a client that
   knows that more requests on a connection are unlikely within the
   discovered timeout interval can close the connection immediately
   after a poll, releasing resources.

"""

Point of information, to my knowledge, Chromium does *not* "choose not to
send non-idempotent requests on idle connections". In my tenure working on
Chromium's network stack I have not seen any bugs related to this.
Therefore, I do not know that we're particularly interested in making use
of this header, but am very curious to hear what motivated it, in case
perhaps we should.

* Are there existing problems that other clients are seeing that motivate
having servers implement this header for better client connection reuse
algorithms?
* What are clients planning to do for this? This is a hop-by-hop header, so
in order to take advantage of this, would clients have to know the
roundtrip time to the next hop? How are clients determining this? Based off
connect() times?
* As I understand it, the Chromium bug reporter is asking for non-compliant
behavior here, right? It's not the client's responsibility to close the
connection, it's the server's responsibility to send a FIN to close down
its send stream. I ask because then doing nothing (as Chromium currently
does) is perfectly compliant behavior. I see no reason for Chromium to
unnecessarily wake up the network link (especially in the mobile case when
that requires powering up the radio) to close down a connection.
* Do we believe that existing intermediaries will actually discard the
header as described in section 3?

Sorry if I've misunderstood anything. I tried to look up discussion about
this I-D on the mailing list archives, but was unable to find anything. If
there's previous discussion I should read, please link me and I'll be happy
to read it prior to sending more ignorant questions regarding this subject.

Cheers.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 11 Nov 2012 08:49:54 +0100

Hi William,

> of this header, but am very curious to hear what motivated it, in case

So that means that Chromium *does* send POST requests over uncertain links
for example ? How does it handle one of the various failures :
  - connection close received after a few hundreds of milliseconds without
    a status code (you don't know if the request was received and is being
    processed) ;

  - no response, possibly meaning a connection hang in the middle, or a
    long processing time on the server ;

In either case, does it automatically retry or does it try to explain to
the user what happened ?

> having servers implement this header for better client connection reuse

Yes, see above :-)

HTTP spec explicitly forbids the UA from retrying non-idempotent requests
after a failure, which means that if the UA decides to send such a request
over a keep-alive connection, it must then let the end user decide what to
do with a possible failure.

The header intends to inform the whole chain about the expected life time
of the connection so that clients and even intermediaries can decide whether
or not it appears safe to reuse an existing connection. Of course there is
no 100% guarantee, but it's much better than what we all have to deal with
at the moment.

Cheers,
Willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 11 Nov 2012 00:18:12 -0800

It appears my messages require moderation, so I apologize to the list if
they appear delayed.

>     a status code (you don't know if the request was received and is being

https://code.google.com/searchframe#OAMlx_jo-ck/src/net/http/http_network_transaction.cc&exact_package=chromium&l=1278

If we reused an idle connection, then we retry with another connection, not
necessarily a new one either.

>     long processing time on the server ;

We don't time out requests. It just spins. The user usually does something
if it hangs for too long.

> In either case, does it automatically retry or does it try to explain to

Yes for the first case, no for the second.

> do with a possible failure.

I'm having trouble finding the relevant section in 2616 which says this.
Can you link me?

> no 100% guarantee, but it's much better than what we all have to deal with

Can you answer my other questions, especially the one which is intended to
clarify how a client would effectively use the information in the header?

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 11 Nov 2012 10:38:19 +0100

Hi William,

> It appears my messages require moderation, so I apologize to the list if

OK. You should probably subscribe, hybi has very low traffic these days,
you won't be spammed.

> necessarily a new one either.

OK so that means you can send multiple non-idempotent requests then ?
That's very dangerous, it possibly is one of the reasons why one of my
colleagues received two books a few years ago while ordering only one
(but he paid twice).

> if it hangs for too long.

OK. However some environments this can become tricky : with WiFi it's easy
to get reassigned a new IP very often when losing connectivity, and outgoing
packets will just be dropped. Similarly in mobile environments, if the PDP
context is lost and re-established, you have no way of knowing this and idle
connections will easily time out.

> Yes for the first case, no for the second.

OK, however as I said this is extremely dangerous and even explicitly
forbidden by 2616.

> I'm having trouble finding the relevant section in 2616 which says this.

Yes, sorry, it's 8.1.4, practical considerations.

> clarify how a client would effectively use the information in the header?

The informat would tell the client whether or not there is a risk to reuse
an idle connection. By having the whole intermediary chain update the header
on the response path, the client knows that reusing a connection that remained
idle for close to the advertised time is very likely going to cause issues.

It will also allow the client to inform the whole chain about its desired
connection duration. This would for example allow intermediaries to increase
their timeouts from their default values, to better satisfy the client's
needs.

Of course the header will not tell you if a NAT box is going to timeout in
the chain. However intermediaries that are configured according to their
surrounding environments might proxy that information. For example, when
you have a firewall with 60s timeouts close to your proxy, you don't set
your proxy timeouts to 60s, but rather to 50-55s max. This will naturally
be reflected in the keep-alive header.

To be clear, I'm quite certain this is not the universal solution to all
issues, but I think it may improve the overall connection quality on the
net.

Cheers,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 12 Nov 2012 22:37:56 +0200

On 11/11/12 10:18 AM, William Chan (陈智昌) wrote:
> It appears my messages require moderation, so I apologize to the list 
> if they appear delayed.
Hi William,

your messages are moderated because you are not subscribed to the hybi 
mailing list.

If you want to contribute to the discussion you are more then welcome
but please subscribe to the ml
https://www.ietf.org/mailman/listinfo/hybi

thanks
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com