[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-hybi-websocket-multiplexing

HyBi Working Group                                            J. Tamplin
Internet-Draft                                                T. Yoshino
Intended status: Standards Track                            Google, Inc.
Expires: April 23, 2012                                 October 21, 2011


                 A Mulplexing Extension for WebSockets
                    draft-tamplin-hybi-google-mux-00

Abstract

   The WebSocket Protocol [WS] requires a new transport connection for
   every WebSocket connection.  This presents a scalability problem when
   many clients connect to the same server, and is made worse by having
   multiple clients running in different tabs of the same user agent.
   This extension provides a way for separate logical WebSocket
   connections to share an underlying transport connection.

   Please send feedback to the hybi@ietf.org mailing list.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 23, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Tamplin & Yoshino        Expires April 23, 2012                 [Page 1]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Interaction with other Extensions / Framing Mechanisms . . . .  4
   3.  Channels . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Flow Control . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Framing  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Multiplex Control Frames . . . . . . . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Buffering  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Proxies  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   12. Nesting  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19





























Tamplin & Yoshino        Expires April 23, 2012                 [Page 2]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


1.  Overview

   This document describes a MUX extension to the WebSocket protocol.
   Initially, it will be identified by the private-use token "x-google-
   mux".  A client that supports this extension will advertise support
   for it in the initial handshake using the "Sec-WebSocket-Extensions"
   header.  If the server supports this extension and supports
   parameters compatible with the client's request, it accepts the use
   of this extension in the handshake response.










































Tamplin & Yoshino        Expires April 23, 2012                 [Page 3]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


2.  Interaction with other Extensions / Framing Mechanisms

   Any compression extensions negotiated apply only to the channel they
   are negotiated on -- therefore, any compression extension in the
   initial handshake applies only to logical channel 1.  If WebSocket
   payload data is masked by a per-frame key, such masking is applied to
   frames for each logical channel separately.

   If other negotiated extensions define extension data, the other
   extension defines whether it applies to just one logical channel (it
   is expected that most extensions will do so) or the physical channel.
   If the other extension applies to one logical channel, it always
   comes after the MUX extension data; otherwise the order depends on
   the order the extensions were listed during the handshake response.





































Tamplin & Yoshino        Expires April 23, 2012                 [Page 4]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


3.  Channels

   The MUX extension maintains separate logical channels, each of which
   is fully the logical equivalent of an independent WebSocket
   connection, including separate handshake headers.  If the MUX
   extension is successfully negotiated, the headers on the initial
   handshake are automatically taken to mean channel 1, which is
   implicitly opened by completing the handshake.  New channels are
   added by the client issuing the AddChannel command (note that only
   the client may initiate new WebSocket connections), including any
   request headers which do not have the same value as the initial
   handshake.  The server's AddChannel response likewise includes any
   response headers which are different from the initial handshake (the
   details of this are TBD, but a simple suggestion for a delta encoding
   is given below).  Channel 0 is reserved for mux control messages and
   does not contain payload data from any logical channel.  A client
   which attempts to add a channel to an existing connection that is not
   accepted by the server SHOULD attempt a new WebSocket connection.

   Once the MUX extension is negotiated on a connection, all frames must
   be prefixed with a channel number in the extension data field.
   Control frames with a channel id 0 refer to the physical connection,
   other control frames MUST be delivered on the logical channel in
   order with data frames for that logical channel.  Control frames
   SHOULD be sent only on channel 0 where possible, though control
   frames for other extensions in particular may need to apply to
   individual logical channels.

   A receiver MUST fail the physical connection and all open logical
   channels if any of these rules are violated by the sender.





















Tamplin & Yoshino        Expires April 23, 2012                 [Page 5]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


4.  Flow Control

   Each logical channel, including the implicitly created channel 1, is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining quota, and the receiver MUST fail the logical
   channel for any sender that does so.  This quota is replenished via
   control messages as the receiver processes the data.

   The initial quota is specified with the "quota" extension parameter,
   and defaults to 64k (TBD) if it is not specified.  The client and
   server each may specify a "quota" parameter and these are unrelated
   -- each specifies how many bytes the other side may send without
   acknowledgement.  The quota values in the initial handshake apply to
   the implicitly opened channel 1.




































Tamplin & Yoshino        Expires April 23, 2012                 [Page 6]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


5.  Framing

   If the extension is successfully negotiated during the handshake, all
   frames have a channel id in the extension data.  The channel ID is
   encoded as a variable number of bytes, as follows:

     0 1 2 3 4 5 6 7
    +-+-------------+
    |0|channel id(7)|
    +-+-------------+

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+---------------------------+
    |1|0|      channel id (14)      |
    +-+-+---------------------------+

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-----------------------------------------+
    |1|1|0|             channel id (21)             |
    +-+-+-+-----------------------------------------+

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+---------------------------------------------------------+
    |1|1|1|                     channel id (29)                     |
    +-+-+-+---------------------------------------------------------+

   The base spec requires that a sequence of frames on the wire be a
   frame with an opcode other than 0, zero or more frames with opcode 0
   and the FIN bit clear, and terminated by a frame with the FIN bit set
   (which may be the initial frame in the case of an unfragmented
   message).  The MUX extension relaxes this requirement to be for just
   frames of one logical channel, and that frames of other logical
   channels may be interleaved arbitrarily.

   All frames with a non-zero channel id must be delivered to the
   specified logical channel in the order they are received, though
   fragmentation may be changed if appropriate.  Control frames with a
   non-zero channel id may also trigger additional processing by the MUX
   extension.

   Control frames with a channel id of 0 refer to the physical
   connection, and may also trigger additional processing - for example,
   a close frame on the physical channel will close all logical channels
   as well (details TBD).




Tamplin & Yoshino        Expires April 23, 2012                 [Page 7]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


6.  Multiplex Control Frames

   Data frames with a channel id of 0 are MUX control frames.  Unless
   another negotiated extension defines a meaning for them, any frames
   on channel 0 with an opcode other than "binary" MUST trigger a
   failure of the physical connection.  Binary frames on channel 0 are
   MUX control frames, and the payload consists of a zero or more MUX
   control blocks, each defined as follows:

   o  a channel number encoded the same as that in the extension data
      (designated as ctrl-channel)

   o  an opcode and data interpreted according to that opcode as
      follows:

     0 1 2 3 4 5 6 7
    +-----+---------+
    | opc | opcdata |
    +-----+---------+

   o  zero or more bytes defined by the opcode

   The opcodes defined are:

   0 - AddChannel request (only from client)  Create a new logical
      channel as ctrl-channel, exactly as if a new connection were
      received on a separate transport connection, except for the
      encoding of the headers. opcdata is interpreted as follows:

     3 4 5 6 7
    +-+---+---+
    |R|enc|len|
    +---------+


      R is reserved for future use, len is the number of bytes used to
      represent the length of following headers minus 1, and enc is an
      encoding type:

      0 - uncompressed  The header bytes that follow are uncompressed,
         and constitute the complete set of headers that would have been
         sent on a WebSocket connection request

      1 - delta-encoded  The header bytes that follow are delta-encoded,
         where any header that is not given is assumed to have the same
         value as that given on the initial request of the physical
         connection.  A header with an empty value means that header is
         not inherited from the initial connection.  (TBD: this means



Tamplin & Yoshino        Expires April 23, 2012                 [Page 8]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


         that valueless headers cannot be encoded with this scheme).

      2-3 - reserved  Reserved for future use


      The following n bytes, where n is the value of len inside opcdata
      plus 1, are an 8-32 bit length of the request header data that
      follows, in network byte order.  The request header data consists
      of a series of lines, separated by a CR-LF pair and terminated by
      an extra CR-LF pair.  The first line is the full URI for the new
      connection, and the remaining lines are the request headers,
      encoded in UTF8 and as defined by the enc value in opcdata.

      The initial quota for the new connection is 0, so the client may
      not send any data for this connection until the AddChannel
      response is received.

      The server always responds with an AddChannel response message,
      described below.

   1 - AddChannel response (only from server)  opcdata is defined as
      follows:

     3 4 5 6 7
    +-----+---+
    |F|enc|len|
    +-----+---+


      RSV is reserved for future use, F is true if this response
      indicates a failure to add the requested channel, len is the of
      bytes used to represent the length of following headers minus 1,
      and enc is an encoding scheme defined as in the AddChannel
      request.

      If F is set, then the server has rejected the request to add a new
      channel and this should be treated exactly the same as if a
      separate connection was attempted and the handshake failed. enc is
      ignored in this case, and the following n bytes, where n is the
      value of len inside opcdata plus 1, are an 8-32 bit length of the
      request header data that follows, in network byte order.  The
      request header data consists of a series of lines, separated by a
      CR-LF pair and terminated by an extra CR-LF pair.  These lines
      should be treated as the response to an HTTP Upgrade request for
      the WebSocket URI, For example:

    HTTP/1.1 404 Not found




Tamplin & Yoshino        Expires April 23, 2012                 [Page 9]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


    404 message body...


      If F is not set, then the server has accepted the request.  The
      following n bytes, where n is the value of len inside opcdata plus
      1, are an 8-32 bit length of the request header data that follows,
      in network byte order.  The request header data consists of a
      series of lines, separated by a CR-LF pair and terminated by an
      extra CR-LF pair.  These are encoded according to enc as defined
      in the AddChannel request, and the complete set of headers after
      decoding is treated exactly as if it was received in response to a
      handshake on a separate connection.

   2 - FlowControl  opcdata is defined as follows:

     3 4 5 6 7
    +-----+---+
    | RSV |len|
    +-----+---+


      RSV is reserved for future use, and len is the number of bytes in
      the quota minus 1.

      The following n bytes, treated as an unsigned integer in network
      byte order, is added to the quota of the number of bytes the
      receiver can have outstanding towards the sender of the
      FlowControl message.  (TBD: is it worth having some non-linear
      encoding to reduce the average bits required to represent these
      values?)

   3-7 - reserved  Reserved for future use (TBD: do we need some support
      for quiescence?)


















Tamplin & Yoshino        Expires April 23, 2012                [Page 10]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


7.  Examples

   _This section is non-normative._

   The examples below assume the handshake has already completed and the
   x-google-mux extension was negotiated.

   01 06 01 "Hello" 81 04 02 "bye" 80 07 01 " world"

      This is a fragmented text message of "Hello world" on channel 1
      interleaved with a text message of "bye" on channel 2.  Note that
      the sequence of opcodes/FIN bits cannot be understood without
      considering the channel id of each frame.






































Tamplin & Yoshino        Expires April 23, 2012                [Page 11]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


8.  Client Behavior

   When a client is asked to make a new WebSocket connection, it MAY
   choose to use an existing WebSocket connection if all of the
   following are true:

   o  the MUX extension was successfully negotated on that connection

   o  the scheme portions of the URIs match exactly

   o  the host portions of the URIs either match exactly or resolve to
      the same IP address (TBD: consider DNS rebind attacks)

   o  the port portions of the URIs (either explicit or implied by the
      scheme) match exactly

   o  the connection has an availablle logical stream id

   If the client chooses to reuse an existing MUXd connection, it sends
   an AddChannel message as described above.  If the AddChannel is
   successful, WebSocket frames may be sent over that channel as normal.
   If the server rejects the AddChannel, the client SHOULD attempt to
   open a new physical WebSocket connection (for example, in a shared
   hosting environment a server may not be prepared to multiplex
   connections from different customers despite having a single IP
   address for them).

























Tamplin & Yoshino        Expires April 23, 2012                [Page 12]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


9.  Buffering

   There will be lots of small frames sent in this protocol
   (particularly replenishing send quotas), so a sender SHOULD attempt
   to aggregate MUX blocks into larger WebSocket frames.  However, care
   must be taken to avoid introducing excessive latency - the exact
   heuristics for delaying in order to aggregate blocks is TBD.












































Tamplin & Yoshino        Expires April 23, 2012                [Page 13]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


10.  Fairness

   A MUX implementation MUST ensure reasonable fairness among the
   logical channels.  This is accomplished in several ways:

   o  by restricting the send quota of a logical channel, the receiver
      can make sure that sender cannot dominate its buffer space

   o  when sending data, the sender MUST use a fair mechanism for
      selecting which logical channel's data to send in the next
      WebSocket frame.  Simple implementations may choose a round-robin
      scheduler, while more advanced implementations may adjust priority
      based on the amount or frequency of data sent by each logical
      channel.

   o  logical channel frames that are sent SHOULD be limited in size
      (such as by refragmenting) when there is contention for the
      physical channel to minimize head-of-line blocking

































Tamplin & Yoshino        Expires April 23, 2012                [Page 14]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


11.  Proxies

   Proxies which do not mux/demux are not affected by the presence of
   this extension -- they simply process WebSocket frames as usual.
   Proxies which filter or monitor WebSocket traffic will need to
   understand the MUX extension in order to extract the data from
   logical connections or to terminate individual logical connections
   when policy is violated.  Proxies which actively multiplex
   connections or demultiplex them (for example, a mobile network might
   have a proxy which aggregates WebSocket connections at a single cell
   to conserve bandwidth to the main gateway) will require additional
   configuration (perhaps including the client) that is outside the
   scope of this document.






































Tamplin & Yoshino        Expires April 23, 2012                [Page 15]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


12.  Nesting

   TBD: Should we allow nesting of MUX'd channels, or should we require
   that an intermediary MUXing channels flatten it?  The advantage of
   nesting is it is conceptually cleaner and less work for an
   intermediary, while the disadvantage is that flow control messages
   will get amplified by nesting and the ultimate server's job is a bit
   more complicated to keep a tree of channel mappings.











































Tamplin & Yoshino        Expires April 23, 2012                [Page 16]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


13.  Security Considerations

   TBD
















































Tamplin & Yoshino        Expires April 23, 2012                [Page 17]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


14.  Normative References

   [WS]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
         draft-ietf-hybi-thewebsocketprotocol-17 (work in progress),
         September 2011, <http://tools.ietf.org/html/
         draft-ietf-hybi-thewebsocketprotocol-17>.













































Tamplin & Yoshino        Expires April 23, 2012                [Page 18]


Internet-Draft    A Mulplexing Extension for WebSockets     October 2011


Authors' Addresses

   John A. Tamplin
   Google, Inc.

   Email: jat@google.com


   Takeshi Yoshino
   Google, Inc.

   Email: tyoshino@google.com







































Tamplin & Yoshino        Expires April 23, 2012                [Page 19]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/