Re: Benjamin Carlyle http 2.0 expression of interest

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