Re: [hybi] Multiplexing extension spec draft 03
"Arman Djusupov" <arman@noemax.com> Fri, 23 March 2012 09:38 UTC
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CCC21F854D for <hybi@ietfa.amsl.com>; Fri, 23 Mar 2012 02:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level:
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sGdXf20ZFTn for <hybi@ietfa.amsl.com>; Fri, 23 Mar 2012 02:38:14 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 893FA21F8548 for <hybi@ietf.org>; Fri, 23 Mar 2012 02:38:14 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id HMJ07711; Fri, 23 Mar 2012 11:38:11 +0200
From: Arman Djusupov <arman@noemax.com>
To: 'Takeshi Yoshino' <tyoshino@google.com>
References: <CAH9hSJb1ewPO3EBgD78anD+=4XouToGR4X7C1wvWqonc2nYB6g@mail.gmail.com> <000301cd05dd$c8f9fc70$5aedf550$@noemax.com> <CAH9hSJYni6BboWdjkLX9xsguph7wJwjAmTUD1genFzT0ja5Wdw@mail.gmail.com>
In-Reply-To: <CAH9hSJYni6BboWdjkLX9xsguph7wJwjAmTUD1genFzT0ja5Wdw@mail.gmail.com>
Date: Fri, 23 Mar 2012 11:38:18 +0200
Message-ID: <003b01cd08d8$b1dd7050$159850f0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CD08E9.75692680"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZeVD36uQA==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2012 09:38:17 -0000
Hello Takeshi, Currently the specification does not make it clear which side assigns a channel ID when an AddChannel control message is sent. I think this could be made flexible; for example if Objective Channel ID is set to 0 then this means that the client prefers the server to select the channel ID, if it is greater than 1 then the client requests a specific channel ID. Giving the client the option to select the channel ID can facilitate the use of application-specific channel IDs, where the predefined logical channel ID is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice channel, 3 - Control channel, 4 - Subtitles channel (optional). It is also worth mentioning in the spec that the protocol specified by the Sec-WebSocket-Protocol header MAY define a default set of logical channels that are considered as being implicitly established when the mux extension is agreed. Some protocols, as mentioned above, may require a fixed set of channels with predefined IDs. Negotiating the same set of channel IDs using an AddChannel request<->response every time a new connection is established would not be efficient. It should be permitted for the "protocol" to imply a default set of channels that don't need to be negotiated (at least this should not be against the specification). As an example, when Sec-WebSocket-Protocol set to "smart-playback" would mean then once the mux is negotiated the following logical channels are considered already established: 1 - Video, 2 - Voice, 3 - Control, 4 - Subtitles. I think this would make the specification much more versatile. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Friday, March 23, 2012 8:22 AM To: Arman Djusupov Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 03 The idea in my mind is that the DropChannel command works similar to TCP FIN/RST when no mux is used. I.e., each logical channel still exchanges close frames (with their channel ID in extension data portion) and uses status code in them (e.g. CloseEvent's code attribute), and after handling them, each side issues the DropChannel command as well as TCP shutdown. So, there's no such problem with graceful shutdown for logical channels' traffic. In terms of control traffic, we may receive some mux command for logical channel X after sending DropChannel command for X, but for now we can just ignore any of control commands safely: - FlowControl X -> safe to ignore - DropChannel X -> no problem. it's totally fine that both sides drop the same channel at the same time. - AddChannel X -> if we receive this, it just means the other peer is misbehaving That said, we can't distinguish this from invalid commands sent by broken peers (e.g. logical channel Y never existed but received command for Y). Maybe it's better to have endpoints respond to DropChannel as well as close frame to sync active channel list. Thanks Takeshi On Mon, Mar 19, 2012 at 23:37, Arman Djusupov <arman@noemax.com> wrote: The procedure of closing the logical channel is not detailed enough. Closing the logical channel should be performed in a way similar to closing the websocket connection when no mux extension is used. We need a close control frame to roundtrip in order to ensure the mutual agreement between the two sides when a logical channel is closed. Currently the specification does not require the side that receives a DropChannel control frame to reply to it (unless I missed something), which does not ensure the graceful closure of logical channels. "When an endpoint received DropChannel, the endpoint MUST remove the logical channel and the application instance that used the logical channel MUST treat this as closure of underlying transport." One side could be in the process of sending a message when it receives a DropChannel frame, so it is important to ensure that the logical channel is closed gracefully without dead channel frames left on the wire. The best way to do it is to let the DropChannel frame roundtrip back to its sender. When both sides have received the DropChannel frame they are in mutual agreement to release the channel ID, being sure that no more frames with the same channel ID are expected to arrive from the remote side. With best regards, Arman
- [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Tobias Oberstein
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Tobias Oberstein
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Tobias Oberstein
- Re: [hybi] Multiplexing extension spec draft 03 Julian Reschke
- Re: [hybi] Multiplexing extension spec draft 03 Greg Wilkins
- Re: [hybi] Multiplexing extension spec draft 03 Joakim Erdfelt
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Greg Wilkins
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Greg Wilkins
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 Takeshi Yoshino
- Re: [hybi] Multiplexing extension spec draft 03 John Tamplin
- Re: [hybi] Multiplexing extension spec draft 03 Arman Djusupov