Re: [hybi] how do we move forward on agreeing on framing?

["Shelby Moore" <[e-mail]>]

Critical point follows...

>>> I don't think that is the case since I'm likely to have to
>>> load-balance millions or billions of connections and not have the
>>> ability to modify or place interesting requirements on the servers
>>> while remaining competitive.

> Shelby Moore wrote:
>> However, we can access probabilities, and thus prioritize [snip]
>> so as to reduce conflation errors that accumulate as brittle
>> complexity inertia.
>>
>> Are you designing an orthogonal layer in a protocol stack (correct
>> engineering) [snip] ?

> Francis Brosnan Blázquez wrote:
>> While I see interesting the case you are exposing (zillions of
>> connections), it does not make it a representative case at all. As you
>> know, good protocol design is based on function delegation: each layer
>> makes a particular defined function.

> Actually, good protocol design is about making stuff that works.
> Anything else is very much a secondary consideration, and while certain
> principles are useful, the one I'm most concerned with is the end-to-end
> principle, which (loosely) states that you minimize the amount of smarts
> in intermediaries, and force complexity to the ends.

http://en.wikipedia.org/wiki/End-to-end_principle

That applies to fragmentation but not multiplexing, because fragmentation
is required by all ends (i.e. there is no minimum frame size that can be
guaranteed to go through all "dumb" networks), whereas multiplexing is an
optimization not required by all possible ends.

A key point about multiplexing is that the "dumb" network can route it
even when it is not in the base protocol the network understands?  In
other words, only the two ends that agree to multiplex, need to know that
there is a multiplexing capable protocol layer on top of the base
protocol.

Fragmentation must be in the base protocol and multiplexing MUST not be,
if you want to follow correct and enduring engineering principle of
maximizing re-use and interoperability.

>> I still believe WS should focus more on transport features and let
>> application protocols on top of it to complete the work....
>>
>> ...because it will be always better than any solution worked by the WG.
>> In other words: let the people to choose what to place on top of WS.

> No, because it means that intermediaries need to work higher up the
> stack in order to do things like multiplexing and refragmentation, both
> of which are very low-level tasks.

The intermediaries are the ends in the case of multi-plexing, because
beyond them, the data has been de-multiplexed and is now just pure base
protocol. In other words, multi-plexing is NOT a low-level task.

And as explained above, fragmentation is a low-level task.