Re: [MMUSIC] RTSP 2.0: Section 18.20: Sequence numbering.

[Magnus Westerlund <[e-mail]>]

Hi Elwyn,

Thanks for spotting ttis. Yes, I agree this is inconsistent, and needs
clearer text.

On 2013-10-09 17:16, Elwyn Davies wrote:
> In the proces of checking the changes from v34 to v37, I found that
> there have been some changes to the CSeq specification  (Section 18.20)
> that seem a bit garbled.
> 
> In para 1, it is stated:
>> For each new RTSP request an agent creates the CSeq value
>>    MUST be incremented by one.
> 
> Then later:
>> 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. 
> 

This is actually not really a contradiction to the first sentence. You
can require to send with monotonically increasing sequence numbers, and
require the receiver to not throw a fit if the received messages are not
having monotonically increasing sequence numbers. However, it doesn't
result in the effect I was after. So it needs reformulation.

> and
>> 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 first requirement is contradicted by the second and third stories.

I think the way of fixing this is to clarify that the first statements
are for RTSP agents originating requests. RTSP Proxies that aggregates
requests on a transport MUST renumber to have monotonically increasing
sequence numbers on that next hop transport. However, Proxies that
aggregates responses towards an agent just maps back the (if necessary)
the sequence numbers the corresponding requests had. And there is okay
for that proxy to send responses out of order due to their potentially
different request targets. Thus, requests must be forwarded in order and
processed in order at the request's destination, the responses can
arrive out of order.

This will work even if there is unreliable transport. A lost response
will result in a retransmitted request, that the next hop that received
(and potentially cached) can retransmit the response.

> 
> We also have:
>> It also enables detecting loss of a request
>>    and await a retransmission prior to processing a sub-sequent request
>>    when using unreliable transport.  
> 
> I understood that RTSP/2.0 is only specified to run over reliable
> transports, so this either requires some usage of the subjunctive mood
> or maybe deletion.  However, having non-sequential CSeq values would
> indeed screw up any future usage of unreliable transport.
> 
> I wonder if this can be handled by changing the increment requirement so
> that it applies to requests sent down a given server connection (or
> channel).  Then if unreliable transports ever did come back, the
> sequencing would still work on a per source/destination address/port
> quadruple (or whatever), while giving unique (but not necessarily
> integer sequential) numbering on the multiplexed connections.
> 
> Anyway, I think that this section needs another pass to sort out the
> inconsistencies.

Yes, below you find a rewrite of the text. I tried writing this with
minimal exceptions for proxies. So please review it so that you think
you understand it and agrees with the rules.

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 each new RTSP request an agent
   originates on a particular RTSP message transport the CSeq value MUST
   be incremented by one.  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.  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.  The RTSP agent receiving requests MUST process the
   requests arriving on particular transport in the order of the
   sequence numbers.  Responses are sent in the order they are
   generated.  The RTSP response MUST have the same sequence number as
   present in the corresponding request.  A RTSP Agent receiving a
   response MAY receive the responses out of order compared to the order
   of the requests it sent.  Thus, the agent MUST use the sequence
   number in the response to pair it with the corresponding request.

      The main purpose of the sequence number is to map responses to
      requests.

      The sequence number requirement on using increment of one for each
      new request is to support any future specification of RTSP message
      transport over a protocol that don't provide in order delivery or
      is unreliable.

      The above rule regarding initial sequence number may appear
      unnecessary loose.  However, they are allowing for a behavior
      which is not uncommon.  When using multiple reliable 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.  For any unreliable transport a
      stricter definition will be required to enable detection of any
      loss of the first request.

      When using multiple sequential transport connections, there is no
      protocol mechanism to ensure in order processing as the sequence
      number is scoped on the individual transport connection and its
      five tuple.  Thus, there are potential issues with opening a new
      transport connection to the same host for which there already
      exist a transport connection with out standing requests and send
      requests related to the same RTSP session.

   RTSP Proxies also needs to follow the above rules.  This implies that
   proxies that aggregates requests from multiple clients onto a single
   transport towards a server or a next hop proxy needs to renumber
   those request to form a joint sequence number on that transport,
   fulfilling the above rules.  A proxy capable of fulfilling some
   agents request without emitting its own request, also causes a need
   to renumber as the number of received requests with a particular
   target, may not be the same as the number of emitted requests towards
   that target agent.  A proxy that needs to renumber, needs to perform
   the corresponding renumbering back to the original sequence number
   for any received response.  A proxy MUST maintain the order between
   responses related to requests originating from the same agent.

      A client connected to a proxy, and using that transport to send
      request to multiple servers creates a situation where it is quite
      likely to receive the responses out of order.  This as the proxy
      will establish different transports from the proxy to the servers
      and forward the client's requests on.  When the responses arrive
      from the different servers they will be forwarded to the client in
      the order they arrive at the proxy and can be processed, not the
      order of the sequence numbers.  This is intentional to avoid some
      sessions requests being blocked by another server's slow
      processing of requests.


Cheers


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------