Subject: [MMUSIC] RTSP 2.0: Sequence number handling and proxies

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Sep 2013 14:16:42 +0200

WG,

As part of Robert's minor issues was a discussion about sequence number
handling, both in checking received increments over reliable as well as
proxy handling.

Martin and I have worked on this and have a proposal:

1. Request senders always increment with one.
2. Receiver over reliable transport does not verify increment
3. Proxies rewrites outgoing sequence numbers when necessary
  * Always needed in many client to a proxy to one server
  * Not required for one client to many servers over same proxy
    due to 2.
4. Proxies can forward responses out of order when they come from
different destinations compared to request order. Avoids head-of-line
blocking by one destination.

The resulting text are changes in section 10.2, 15.2 and 18.20 that we
wish you to review.

Added at end of 10.2:

   RTSP Agents can send requests to multiple different destinations,
   either servers or client contexts over the same connection to a
   proxy.  Then the proxy forks the message to the different
   destinations over proxy to agent connections.  In these cases when
   multiple requests are outstanding the requesting agent MUST be ready
   to receive the responses out of order compared to the order they
   where sent on the connection.  The order between multiple messages
   for each destination will be maintained, however, the order between
   response from different destinations can be different.

      The reason for this is to avoid a head of line blocking.  In a
      sequence of request an early outstanding request may take time to
      be processed at one destination.  Simultaneously a responses from
      any other destinations, that was later in the sequence of requests
      may have arrived at the proxy.  Thus allowing out-of-order
      responses avoid forcing the proxy to buffer this response and
      instead deliver it as soon as possible.  Note, this will not
      affect the order they where processed at request destination.

   This scenario can occur in two cases involving proxies.  The first is
   a client issuing requests for sessions on different servers using a
   common client to proxy connection.  The second is for server to
   client requests, like REDIRECT being sent by the server over a common
   transport connection the proxy created for its different connecting
   clients.

15.2.  Multiplexing and Demultiplexing of Messages

   RTSP proxies may have to multiplex multiple RTSP sessions from their
   clients towards RTSP servers.  This requires that RTSP requests from
   multiple clients are multiplexed onto a common connection for
   requests outgoing to an RTSP server and on the way back the responses
   are demultiplexed from the server to per client responses.  On the
   protocol level this requires that request and response messages are
   handled in both ways, requiring that there is a mechanism to
   correlate what request/response pair exchanged between proxy and
   server is mapped to what client (or client request).

   This multiplexing of requests and demultiplexing of responses is done
   by using the CSeq header field.  The proxy has to rewrite the CSeq in
   requests to the server and responses from the server and remember
   what CSeq is mapped to what client.  The proxy also needs to ensure
   that the order of the message related to each client is maintained.
   Section 18.20 is defining the handling of how requests and responses
   are rewritten.

18.20.  CSeq

   The CSeq general-header field specifies the sequence number for an
   RTSP request-response pair.  This field MUST be present in all
   requests and responses.  For every RTSP request containing the given
   sequence number, the corresponding response will have the same
   number.  For each new RTSP request an agent creates the CSeq value
   MUST be incremented by one.  This primarily allows for associating
   requests with responses.  It also enables detecting loss of a request
   and await a retransmission prior to processing a sub-sequent request
   when using unreliable transport.  Any retransmitted request MUST
   contain the same sequence number as the original, i.e., the sequence
   number is not incremented for retransmissions of the same request.
   Agents receiving a request over a reliable transport with an in-order
   delivery MUST ignore how the sequence value increments, i.e. it can
   increment with other values than 1.  The initial sequence number MAY
   be any number, however, it is RECOMMENDED to start at 0.  Each
   sequence number series is unique between each requester and
   responder, i.e., the client has one series for its request to a
   server and the server has another when sending request to the client.
   Each requester and responder is identified with its socket address
   (IP address and port number), i.e., per direction of a TCP
   connection.

   The above rules may appear unnecessary loose.  However, they are
   allowing for a behavior which is not uncommon.  When using multiple
   connections in sequence it may still be easiest to use a single
   sequence number series for a client connecting with a particular
   server.  Thus, the initial sequence number may be arbitrary depending
   on the number of previous requests.

   Proxies that aggregate several client sessions on the same transport
   will have to ensure that the requests sent towards a particular
   server have a joint sequence number space.  A proxy having one client
   with concurrent sessions with two different servers using the same
   client proxy connection can avoid rewriting on the proxy to server
   connection.  The latest equally applies to server to client requests,
   where one server may have multiple clients over the same proxy.  The
   proxy can use only one joint sequence number space for a given
   transport connection to a particular server for sending request, as
   the identification of the RTSP agents, i.e., the proxy and the server
   is based on the IP address and port number.  This requires that the
   proxy renumbers the CSeq header field in both requests and responses
   to fulfill the rules for the header.

   An RTSP proxy MUST renumber the RTSP request from RTSP agents that
   are sent to a particular RTSP agent in order to preserve the joint
   sequence number space on the connection between the proxy and the
   agent.  The RTSP proxy MUST increase the CSeq for each request it
   transmits over a particular transport connection or transport flow,
   without regard of different sessions.

   An RTSP proxy MUST renumber RTSP responses back to the sequence
   number that the corresponding request had when originally received by
   the proxy before forwarding it to the RTSP agent.

   A proxy that forwards responses from multiple RTSP agents towards a
   specific agent MUST maintain the order between request/responses on a
   per incoming connection basis.  This means that different RTSP
   sessions are handled over the same same transport connection between
   proxy and the specific agent.

   Given that the RTSP proxy and the agents are using reliable transport
   connections, the proxy MAY forward received responses without
   considering the response's relation to responses from other
   connections which will share the same outgoing transport connection
   from the proxy.

         Note: This exception is to avoid responses being blocked by
         other agents being slow to respond.  This can result in out-of-
         order delivery of responses arriving at the RTSP client in
         relation to the transport connection, but that delivery is in-
         order with respect to the RTSP agent and any session.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------