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

From: Elwyn Davies <[email-masked]>
Date: Wed, 09 Oct 2013 16:16:20 +0100

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. 

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.

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.

Regards,
Elwyn

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 9 Oct 2013 15:35:34 -0700

> Anyway, I think that this section needs another pass to sort out the

Or else get rid of the "CSeq" field altogether...

	Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Oct 2013 11:26:07 +0200

Hi Elwyn,

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

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

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

> Anyway, I think that this section needs another pass to sort out the

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Oct 2013 11:28:10 +0200

> Or else get rid of the "CSeq" field altogether...

I don't think that helps. Then we get another set of problems related to
how an originating agent maps requests to responses. Especially in the
relation to proxies. For example you can't have an client use one proxy
and establish two RTSP session with different servers at the same time
without running into blocking issues.

Cheers

Magnus Westerlund

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 10 Oct 2013 12:56:28 +0100

Hi, Magnus.

The text below is better, but there still seem to be a couple of
problems.  I have edited the language and added some comments in the
attached file (embedded in [[..]]).

Regards,
Elwyn

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Oct 2013 16:01:22 +0200

Hi,

Thanks Elwyn for taking a look at these changes. I taken the changes
with two exceptions. In a private email you already had provided a
better rewrite of one of the sentence going into the below motivation.
That I kept, thus that motivation now reads:

      The above rules relating to the initial sequence number may appear
      unnecessarily loose.  The reason is to cater for some common
      behavior of existing implementations: 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 or other solution will be required
      to enable detection of any loss of the first request.

The second thing is this part of the Proxy paragraph:

A proxy MUST maintain the order between
   responses related to requests originating from the same agent.

And your comments.

   [[I don't see why this ordering requirement is needed for TCP -
   above we mandate that agents must be able to handle out of order
   responses.
   Indeed I think this is directly contradictory to the following note!
   UDP would be a different matter but that is out of scope. OTOH
   there might be a need for proxies that actually process responses
   to carry out the processing in the sequence of the incoming requests
   that resulted in the responses - I am not sure if this is ever the
   case.]]

Yes, my sentence become wrong. The requirement was meant to say that the
responses arriving from a particular server may not be reordered.

However, I agree with you that this is both an unnecessary requirement
due to the requirement to actually match based on sequence number.
Secondly, a proxy chain is also unlikely to reorder the responses from a
particular server on the way.

Thus, I will propose that one is removed.

Cheers

Magnus

-- 

Magnus Westerlund