Re: [hybi] Multiplexing extension spec draft 03

Takeshi Yoshino <tyoshino@google.com> Fri, 23 March 2012 06:22 UTC

Return-Path: <tyoshino@google.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 DA4BA21E8039 for <hybi@ietfa.amsl.com>; Thu, 22 Mar 2012 23:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.96
X-Spam-Level:
X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 g+y+TQOisaOH for <hybi@ietfa.amsl.com>; Thu, 22 Mar 2012 23:22:30 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8B8D21E8013 for <hybi@ietf.org>; Thu, 22 Mar 2012 23:22:29 -0700 (PDT)
Received: by yenm5 with SMTP id m5so2738744yen.31 for <hybi@ietf.org>; Thu, 22 Mar 2012 23:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C314BeXJ+i2uSIpCahWTMmOxrXTsRALaTjYbNuGeHTE=; b=N3fxLM7LM/55JBd99117eN+B66cbrKZv49nV5kD13KWlTCJVAHMJcUIdKxdwiALQwl /q8xD9WzmUOJuxcLs/xQy78En5mTZhaY3VFvayWQ6Wlxb672hC+l2i4w8nE2F624hbIW dEQOu3qPUuE9Rn4YbmQpxHandSeye66SOSTYoe5xuN7PMb0dmN9dMlY/9ENswslZd0OF cZe9eDjqQg4v3O+4U7RXJq21FMz2qG29mnyYc+oEY/FE/vRS2w4PYagUgutjVqn/0Sv+ vv7AEx1F41ZdlguB50y6MxQuL+2FRLOQ9hhOtmT1eyhMn0zWo1hkbfzd70h2rLUNe5SO fygg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C314BeXJ+i2uSIpCahWTMmOxrXTsRALaTjYbNuGeHTE=; b=Qk/a+KVbdKSgrTIkdMmRZzuWOOeBAMjHCjExy27xhnI5s9eP0uCXZ83Tl3rFB1VtpT MZy94n1hITAQyFm+VBaLLaOuOLEaO3kJ/6mQ8MJvvsv9JhchOaXvzvT4iLnIVAToaUED EzOEwn6OeDZdhtJOdOzVcMMcrFyR6ZVBUGyVsoCXyd/XHeyFv7C7Ml0QL4dQ5KQcTCz9 HOtnP8ASjACX1HMPfDpiTXyINuktIGcLndqq8k6C9U2KzszXnutD7BHk1tATz5AB8u7T blQx/g0o7Y5if0IielaqDaeGp7rJcoraYPZEDKmmzG/4blm45gFQfpp7LOLVcjx6qs+8 RKaQ==
Received: by 10.236.195.38 with SMTP id o26mr10880546yhn.100.1332483748917; Thu, 22 Mar 2012 23:22:28 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr10880540yhn.100.1332483748749; Thu, 22 Mar 2012 23:22:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Thu, 22 Mar 2012 23:22:08 -0700 (PDT)
In-Reply-To: <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>
References: <CAH9hSJb1ewPO3EBgD78anD+=4XouToGR4X7C1wvWqonc2nYB6g@mail.gmail.com> <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 23 Mar 2012 15:22:08 +0900
Message-ID: <CAH9hSJYni6BboWdjkLX9xsguph7wJwjAmTUD1genFzT0ja5Wdw@mail.gmail.com>
To: Arman Djusupov <arman@noemax.com>
Content-Type: multipart/alternative; boundary="20cf305e276383633304bbe30c43"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmDo0y0h+VvUdo6H4NuphbbPZENfu1yd+rFqLjtS+i2QsXg0+z8Y3grVP9sXpiBzTEMNBvoiPD3J+UJQXoQyig3fYKLAeQBKweWuknoi+qcyZdHC7JygsWtKiwGNxwxPwscAGlq
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 06:22:31 -0000

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
>
>