Re: [hybi] Is there a traffic jam?

[Jamie Lokier <[e-mail]>]

Thomson, Martin wrote:
> > Seems that each request/response would need its own BEEP channel. This
> > is because of the synchronous nature of BEEP channels(*). Channel
> > creation is mid-weight, but at least requires a round-trip before the
> > actual request could even begin. It might be possible to encode the
> > request within the channel creation request, but there is a 4k payload
> > limit for such messages.
> 

> [[MT]] BEEP does pipelining, just like HTTP.

Yes, that's why it sucks :-)

HTTP pipelining is a problem.  Have you noticed that no sane client
sends pipelined POSTs?  There's a reason.

Have you noticed that proxies do not aggregate multiple clients into
fewer connections to the same origin server?  Pipelining not being
asychronous is the main reason why they can't.

For widgets in a web page, the BEEP synchronous restriction forces
application workarounds for "large" messages - such as a large PNG (or
unwanted interference as soon as you mix widgets on a page) - and it
forces each application to have its own addressing layer _above_ the
base protocol if they have multiple widgets on a page all subscribing
for updates which can come in any order.

Basically it prevents lots of widgets from operating independently of
each other over the same channel.  Use separate channels (or server
connections) for a few widgets?  That doesn't scale to 100 or more
widgets per page, which is easy to reach with a bit of imagination.

> Of course, the synchronous restriction is artificial, and there are
> use cases that demand a greater degree of asynchrony.  Hence, the
> draft you refer to.

Unfortunately the asynchrony draft still has an artifical restriction
which makes it useless for independent requests.

> [[MT]] The "XML" parsers I've seen in implementations of BEEP are
> rarely as complex as you make out.  The control channel doesn't demand
> much complexity of a parser.  Now you can take that as an indication
> of the maturity of BEEP implementation if you like, I can't disagree
> about _that_ point...

To be a "correct" BEEP implementation, it needs to correctly parse
XML, including skipping a potential embedded DTD (whose lexical syntax
wasn't even precisely defined in the XML spec last time I looked),
accepting UTF-16 both endians, and things like that.

No problem if you have a good XML library handy, only if you don't.
(Still a bit heavy even if you do, compared with HTTP's headers.)

_Normal_ XML is easy to parse in any language, the problem is a
protocol implementation is allowed to send unusual XML, and a protocol
parser which doesn't handle that is non-compliant.

Is there a new BEEP planning to come out which specifies that the
irrelevant parts of XML will not appear on the wire?  That would be
helpful.  I'm sure I've seen that done in some other IETF documents.

> > There is no addressability in BEEP for channels or messages. I see two
> > ways two add one to a profile: 1) Add the address (and perhaps method)
> > as fields in the initialization message on channel create. This would
> > require a new channel for every request. 2) Encode the address in each
> > message (see above for using message/http)
> 
> [[MT]] If you are looking to interact with the same resource,
> identifying the resource at channel creation time might make sense.
> Alternatively, the MIME headers can be used to identify a resource for
> each request.

I agree with both of those; they make sense to me.

My only objection is that BEEP channel creation needs a round trip -
you can't create them at the request side as needed.

> > The overhead of BEEP seems like it would greater, though I admit I
> > haven't calculated it. I doubt it would be outrageous.
> 
> [[MT]] Greater than websockets?  That seems quite likely.  Depends
> on how much you are using from of what BEEP offers.

Overhead: the initial setup looks similar for each.  After that, BEEP
uses more bytes, but about the same number of network packets.

> > I don't know enough to know if flow control internally would be
> > needed. If so, BEEP has it.  If not, it is a little scary to implement!
> 
> [[MT]] If you want to avoid implementation, it's not actually that
> hard to send an occasional SEQ frame.  It's quite easy to avoid flow
> control being a problem.

Indeed.  Per channel flow control is important - if you have multiple
independent channels, otherwise problems you don't want to care about
bite some applications.

> However, I'll note that flow control in current implementations
> isn't like that - a small fixed window is common, which severely
> limits throughput.  Of course, that's a further sign of stack maturity
> more than anything else, there is nothing in the protocol preventing
> bandwidth-delay product estimation.

Agreed.  Also SCTP instead of TCP is promising - let the operating
system do the estimation for you better.  (There's some discussion of
HTTP over SCTP around, but nothing concrete yet that I know of.)

-- Jamie