Re: Framing and control-frame continuations

["Adrien W. de Croy" <[e-mail]>]

I think the issue in the end is how do we answer this question:  Will 
64k max frame size be enough / appropriate in 20 years time.

It's extremely difficult to fathom where we may be or what a computer or 
network looks like in that time frame.

64k seems too small.  4GB looks to have issues with interleaving and HOL 
blocking.  I can see some simple server authors thinking "cool I can 
send this 4GB file in one frame".  Which may be cool or not depending on 
what else is going on (e.g. may choke a down-stream proxy trying to 
interleave multiple responses - although I guess it could just repackage 
it).

I'm not really a fan of using 24 bits, but it would save 1B/frame.

In the end, we could do something like.

1. make it 32 bits
2. place minimum size limits on size of a control frame that must be 
accepted (e.g. something much smaller).  So implementations can only 
rely on that size being accepted for a control frame.
3. put stern words in about blocking and concurrency when it comes to 
choosing a frame size when sending data.

in the end, TCP has to do a bunch of work underneath to get this over 
1460 bytes of payload anyway.  Until the basic ethernet frame size 
grows, and is reliable across the internet (I'm thinking this will be a 
very long time away) we're going to be constrained by TCP window, and 
ack latency anyway.


Adrien



------ Original Message ------
From: "James M Snell" <[e-mail]>
To: "Mark Nottingham" <[e-mail]>
Cc: "Poul-Henning Kamp" <[e-mail]>; "HTTP Working Group" 
<[e-mail]>
Sent: 7/02/2013 11:46:28 a.m.
Subject: Re: Framing and control-frame continuations
>On Wed, Feb 6, 2013 at 2:41 PM, Mark Nottingham <[e-mail]> wrote:
>[snip]
>>
>>  Numbers, please, not handwaving.
>>
>
>+1 ... many times over.
>
>- James
>