Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-01.txt

The mux specification does not define an algorithm for calculating the
subsequent FC quota to be sent to the remote side. This means that the quota
is not required to be a fixed value, it can have a dynamic value taking into
account various criteria including the share of the per-connection window
space available. 

If we have to resolve the overallocation and underutilization issue on the
protocol level, we would need a more complex flow control protocol that
would be able use an optimistic window size and discard/retransmit the
frames that would be overbuffered. This would definitely be much more
complex and I doubt that it would resolve performance problems.

Note that the issues being discussed in the SPDY list are not only SPDY
problems, they are present even with TCP/IP intermediaries (with the
difference that TCP/IP packets can be discarded and retransmitted later if
the link is overloaded).

With best regards,

Arman

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg
Wilkins
Sent: Tuesday, May 22, 2012 12:12 PM
To: Takeshi Yoshino
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action:
draft-ietf-hybi-websocket-multiplexing-01.txt

I think we should note the discussion happening over in SPDY-dev about their
flow control and concerns about it

  https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/JB_aQPNI7rw

Our mux proposal with it's send quotas has effectively the same problem -
namely that a fixed quota per channel can cause a significant under
utilisation of a fast link, but can also represent a significant over
allocation of capacity if many channels are present.  I think we need to
closely follow that discussion to see what solutions may be developed before
we commit to a per channel window flow control.

cheers

On 20 April 2012 08:08, Takeshi Yoshino <tyoshino@google.com> wrote:

Hi all,

Here's the ietf -01 version of multiplexing spec.

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-01
.txt

Changes from -00 are:

- now multiplex control blocks MUST be interpreted when the entire message
containing them has arrived

- now the base for delta-encode of handshake is the last
AddChannelRequest/Response with Enc=identity

- clarified how much the send quota is until receiving reply

-- note that this is still open for discussion

- a server MUST _Fail the Physical Channel_ when there's inconsistency
between Sec-WebSocket-Extensions in AddChannelRequest/AddChannelResponse
(e.g. some value that need to be the same for all logical channels is
altered)

-- another option is to just _Fail the Logical Channel_

- style/readability

-- new term "multiplexed connection" to clarify the difference between
logical channels (used for both control and transferring multiplexed
connection's data) and multiplexed WebSocket connections

-- new term "Implicitly Opened Connection" defined to reduce text

-- made definition of send quota and quota parameter in Flow Control section
more detailed

_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi