Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)

"Arman Djusupov" <arman@noemax.com> Wed, 18 April 2012 13:18 UTC

From: Arman Djusupov <arman@noemax.com>
To: 'John Tamplin' <jat@google.com>, 'Takeshi Yoshino' <tyoshino@google.com>
References: <CAH9hSJZP8FhAGANSwPfvdMCQPyfRhG7tqPT68e6VY5ZCAEROTw@mail.gmail.com> <CABLsOLBsHXsj_A2sWa+b8KaFJBEFMHk0W268RyKzh7J0Y+ZxVQ@mail.gmail.com>
In-Reply-To: <CABLsOLBsHXsj_A2sWa+b8KaFJBEFMHk0W268RyKzh7J0Y+ZxVQ@mail.gmail.com>
Date: Wed, 18 Apr 2012 16:18:36 +0300
Message-ID: <001f01cd1d65$c75807f0$560817d0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD1D7E.ECA53FF0"
Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIl6aPzWA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)
Precedence: list

I also feel it is unnecessary to let the client send some payload that would need to be discarded if the channel is not accepted. 

 

But if this feature is needed for some use cases then I would opt for using the quota negotiated during the initial handshake as the initial quota for all logical channels (and wouldn’t negotiate an initial quota for logical channels since they already have it granted).

 

With best regards,

Arman

 

From: John Tamplin [mailto:jat@google.com] 
Sent: Wednesday, April 18, 2012 3:01 PM
To: Takeshi Yoshino
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics)

 

On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <tyoshino@google.com> wrote:

You're right. In the latest spec, it's not explicitly specified what the value of send quota is until AddChannelResponse is received.

 

There're several options we can take.

 

a) specify the fixed value of send quota before AddChannelResponse in the spec

b) add a new parameter "pre_handshake_quota" to multiplexing extension to negotiate the value of send quota before AddChannelResponse

c) drop the feature to configure initial quota for each logical channel, and redefine the quota parameter as pre-handshake send quota for all logical channels

 

Until we know the AddChannel was accepted, how can we send data anyway?  This seems just like the initial handshake on a new connection -- you wouldn't consider sending that data until you knew the connection was accepted.  Since we are avoiding TCP setup requirements, this will be much less latency than if the connection were created without multiplexing.

 

I suppose it would be possible to send the data while keeping it buffered as an optimization, but since adding a channel should be infrequent compared to sending data on it, I don't see it as that important to optimize for.

 

-- 
John A. Tamplin
Software Engineer (GWT), Google

[hybi] Send quota value before receiving AddChann… Takeshi Yoshino
Re: [hybi] Send quota value before receiving AddC… John Tamplin
Re: [hybi] Send quota value before receiving AddC… Arman Djusupov
Re: [hybi] Send quota value before receiving AddC… Takeshi Yoshino
Re: [hybi] Send quota value before receiving AddC… Gabriel Montenegro
Re: [hybi] Send quota value before receiving AddC… Arman Djusupov
Re: [hybi] Send quota value before receiving AddC… Gabriel Montenegro
Re: [hybi] Send quota value before receiving AddC… Patrick McManus
Re: [hybi] Send quota value before receiving AddC… Greg Wilkins
Re: [hybi] Send quota value before receiving AddC… Arman Djusupov
Re: [hybi] Send quota value before receiving AddC… John Tamplin
Re: [hybi] Send quota value before receiving AddC… Arman Djusupov
Re: [hybi] Send quota value before receiving AddC… Takeshi Yoshino