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

From: Greg Wilkins <[email-masked]>
Date: Tue, 22 May 2012 11:11:39 +0200

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: "Arman Djusupov" <[email-masked]>
Date: Tue, 22 May 2012 14:40:21 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
Wilkins
Sent: Tuesday, May 22, 2012 12:12 PM
To: Takeshi Yoshino
Cc: [email-masked]
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

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

Hi all,

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

Changes from -00 are:

- style/readability

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