Re: Large Frame Proposal

On 2014-07-09 15:42, Roberto Peon wrote:
> Allowing a large frame-size setting for any stream implies a loss of
> reactivity for all other streams within that connection, so long as the
> stream with the larger framesize is used.
> 
> Essentially, it adds HOL blocking in. A frame size of 2^32, would
> potentially imply seconds of latency, and a failure of the protocol to
> deliver adequately.

On a 100Gbps network link the transfer time of 4GB (2^32) is approx. 
0.32 seconds.

The same large frame sent as HEADERS+CONTINUATION causes identical 
problems while also expanding the total transfer size by +2MB of 
CONTINUATION frame headers. That is extra 1.5ms latency at 10Gbps and 
much more at any lower speeds.

The same large frame sent as DATA is:
* uni-directional and negotiated. In order to deliver the recipient has 
already advertised willingness to be blocked by it.
* 2MB smaller than the equivalent set of 16KB DATA frames. (shaves off
* the receiver implementation is free to send back smaller frames and 
control frames
* the receiver is free to re-package as smaller DATA frames for 
tighter/slower next-hop connections.

Also, HTTP traffic wanting such huge frames is in the minority of 
use-cases. Intra/inter -datacenter, "big data", and science networks 
primarily. The take away point being that they do exist already.

> 
> I still find it amusing (in an " I'm so sad that we keep conveniently
> overlooking these things" kind of way) that we're still talking about 
> large
> frames being any kind of improvement at all in the web context when one
> still needs to traverse the TLS library in order to get HTTP2 working
> anyway, and when larger frame sizes cause problems with reactivity, and
> thus induce latency.

Correction: we are talking about larger than *16KB* as being useful for 
some of todays network needs and very useful for some near-future 
projected needs.

You are also omitting the 91% of HTTP traffic which is non-TLS. Some 
portion of which will never become TLS encrypted.


> 
> Larger framesizes matter only for non-TLS connections.
> That is why I'll hope that most browsers and most servers pick 
> framesizes
> that are proportional to the TLS record size, and that are relatively 
> small
> (e.g. 16k or less).

There is effort ongoing to increase the throughput and hardware 
acceleration in the encryption area. We may find that in only a few 
years it is possible to send Gbps out through a hardware encrypting NIC. 
There is also significant ongoing efforts to improve the library basic 
throughputs.

It all comes back to implementations needing to be free to pick the 
right frame sizes for their use-cases. Large or small.


> 
> I'm happy with 16 bits of length. 24 bits of length will slow things 
> down
> marginally in the common case as we're putting 8 more '0's on the wire 
> for
> nothing almost all the time.
> 
> -=R
> 

Amos

Received on Wednesday, 9 July 2014 05:11:14 UTC