Re: Large Frame Proposal

On Jul 10, 2014, at 12:49 PM, K.Morgan@iaea.org wrote:

> To quote Mark from an earlier thread...
>  
> On Wednesday,25 June 2014 06:11, mnot@mnot.net wrote:
> > WRT the "jumbo" frame (i.e., flagging that some prefix of the
> > payload is actually an extension length) -- this sort of hack is
> > necessary to back-port bigger frames onto an existing protocol
>  
> Amen. A 31-bit frame-length field may be too many bits today, but IMO we shouldn't set ourselves up for an ugly hack later.
>  
> So I propose some variant of the following...
>  
>  
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   Reserved    |                  Length (24)                  |
> +-+-------------+-----------------------------------------------+
> |R|                 Stream Identifier (31)                      |
> +-+-------------+---------------+-------------------------------+
> |   Type (8)    |   Flags (8)   |
> +===============+===============+===============================+
> |                   Frame Payload (0...)                      ...
> +———————————————————————————————+

Is that for every frame, or just when a large frame size has been advertised?  I guess the former, but then we’re increasing every frame by 2 bytes for the same of those 0.02% No?

Yoav