- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 24 Jul 2012 10:57:54 +1200
- To: William Chan (ιζΊζ) <willchan@chromium.org>
- Cc: <ietf-http-wg@w3.org>
On 24.07.2012 07:04, William Chan wrote: > On Sun, Jul 22, 2012 at 2:27 PM, Amos Jeffries wrote: > >> On 23/07/2012 4:20 a.m., Roberto Peon wrote: >> >>> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" wrote: <snip> >> > #2 Canonical form or info set >>> > The signature and encryption issues may be the tip of a larger >>> canonicalization ice berg. HTTP has traditionally allowed new >>> headers a >>> level of freedom in defining both semantics and parsing rules. As >>> we move >>> forwards perhaps it is time to place some limits on this. >>> > >>> > #3 Out of order responses and heartbeat capability >>> > Modifying http to be able to make efficient use of a single TCP >>> connection is I think a priority for many members of this list, and >>> is >>> something that SPDY has been specifically developed to address. I >>> would >>> like to expand on this with the specific notion of heartbeats to be >>> able to >>> reliably answer the question: Is my connection alive or dead? If >>> the >>> connection is dead the client will want to know as quickly as >>> possible so >>> that it can connect to a redundant instance of the server. >>> >>> The PING frame in SPDY addresses this, btw. It is especially >>> important >>> for clients behind NATS. >>> >>> > In my use cases I often want positive confirmation that my >>> connection >>> is still valid approximately every four seconds, plus assurances >>> from >>> intermediates that they are also seeing heartbeats. >>> >>> Keep-alive pings are very to distinguish from DoS attacks. Having >>> the >>> server interpret something once every 4 seconds is probably OK at >>> the layer >>> above the protocol layer. >>> >>> > For long poll use cases this can be taken care of by requesting a >>> short >>> timeout in requests and for long database transactions a slow >>> response can >>> be replaced by an asynchronous interaction, but it would be helpful >>> to have >>> the server send regular updates on the processing status for a >>> given >>> request. A regular high priority OPTIONS * request may suffice to >>> solve >>> this problem. >>> >>> >> I'm not sure how useful this is really. Given that multiplexing will >> "fill >> the pipe" a lot better than HTTP/1 ever did. Does anyone from SPDY >> have >> actual numbers on how frequently PING frames are really needed? > > > What kind of numbers are you looking for? I'm not sure what numbers > would > make sense. But I guarantee you it is absolutely necessary. A summary > of > the NAT connection timeout issue can be found at > http://code.google.com/p/chromium/issues/detail?id=27400. We "fixed" > it for > Chromium (before mobile versions were released) by just turning on > TCP > keepalive, which is a horrible hack that doesn't work on mobile > because it > wakes up the radio. The problem exists in HTTP/1 too, but the pain is > mitigated due to generally speaking only single request/response > pairs over > a single TCP connection (which also means reloads would often use a > different TCP connection that worked). For a multiplexed protocol > where you > are trying to share a single connection, a dead connection that isn't > detectable at the application layer results in a horrible user > experience. > I was wondering about metrics like how many PING are actually needed to keep-alive. With X being some value just enough to keep the radio and connection up. If the algorithm for sending them is X milliseconds since last frame do we end up with any PING happening at all? some large % of the PING+request frame count being PING? or only some small % of that count being PING? If the case of large % being PING, is it actual user experience being interrupted or automated background traffic (which could be delayed by the ph itself until user interaction happens instead of drainign battery o keep-alive). Keeping in mind that ph apps do not auto-close any more, so there are potentially N applications all consuming TCP connection, radio time, and power doing PING. Amos
Received on Monday, 23 July 2012 22:58:37 UTC