Re: [hybi] Frame size

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> Scott Ferguson wrote:
> > Greg Wilkins wrote:
> >> In fact, I would argue for a 16k max frame size with 2
> >> bits given over to help with partitioning and aggregation,
> >> but with no requirement that an endpoint can handle
> >> aggregation and partitioning (unless they indicate they
> >> can in the handshake).
> >>   
> > 16k is fine, but why are two bits needed instead of one? 
> 
> 1 bit is fine for pure fragmentation.
> 
> I suggested 2 bits because of previous discussions on
> the list about a bit indicating if an intermediary
> can buffer a frame or not.  This gives the ability
> to have streaming frames plus other frame types
> (see BWTP post for an example of using the 2 bits).
> 
> However we could get the streaming by just having
> a single bit for fragmentation and the spec can say
> that all intermediaries must forward all frames immediately.

That needs clarification.

What does "forward all frames immediately" mean?

If you receive the first _half_ of a frame 10 seconds before the
second half (due to a single dropped packet on a mobile link), do you
have to forward the first half as-is, or is it ok to wait for the second half?

Streaming apps will be penalised if the intermediary applies the
second rule, and message-oriented apps will be penalised if the
intermediary applies the first rule.

One of the timing/latency problems with fixed frame boundaries is they
will tend not to match TCP segment boundaries, making the above
situation very common (but usually much less than 10 seconds).

If intermediaries are permitted to change frame boundaries, as they
are with HTTP chunking, there is much more scope for adapting to TCP
and also fairer multiplexing etc.

I'm thinking if the spec says all frames must be forwarded
immediately, actual implementations will parse the frame headers to
guess when to delay for a short time.

A little bit of information to guide that may be helpful, but I don't
have hard numbers at this time.

I don't think we should prescribe forwarding strategies in a "tight"
way, but we do need to prescribe something minimal.  We should be
aware that immediate forwarding of every byte is _never_ implemented
(there is always a buffering & delaying heuristic at some layer), so
we should recognise that fact, and provide enough flexibility and
guidance so that intermediaries can be developed which makes good
decisions for all styles of application protocols.  We don't have to
specify how exactly.

-- Jamie