Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 17:22:16 +0100

Hi,

This is one of several issues I still see remaining in the document. It
has clearly improved. I am sorry that I become sick before Christmas and
couldn't continue the discussion then.

There is an issue with SSRC usage in this document related to the
different RTP sessions. Please remember that the most fundamental part
of the RTP session definition is that each RTP session has its own SSRC
space.

So there is one SSRC number space for the multicast RTP session. An SSRC
from this space is used in the Token Verification Request to identify
the requesting client. In the Token Verification response message this
SSRC identifier is included in the Token response message. The problem
is that this message is conveyed in the unicast RTP session that has its
own SSRC space. Thus we have potentially create a coupling between the
two RTP sessions.

As I see it this can be fixed in two ways. Either one explicitly notes
that this RTCP Token Response message field carries a value that refers
to the SSRC space in another RTP session then one currently are in. This
is likely the simplest solution.

The alternative is to accept the coupling. But then one has to make
clear on how to handle SSRC collisions. This seems problematic as the
coupled session is a multicast session. A multicast session has bigger
difficulties with changes due to its number of receivers and also that
if one forces an active sender to change it may causes widespread
disruption.

I also observe that it is not clear what SSRC space the Port Mapping
request and response messages uses. Does this need to be synchronized
with any other space or can it be its own unique one. A unique one is
probably easiest. I don't see any direct coupling to the other sessions.

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: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 14 Jan 2011 17:44:43 +0100

Magnus,

Thx for the comment, see below 
Tom
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: vrijdag 14 januari 2011 17:22
To: IETF AVT WG; [email-masked]
Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces

Hi,

This is one of several issues I still see remaining in the document. It has clearly improved. I am sorry that I become sick before Christmas and couldn't continue the discussion then.

There is an issue with SSRC usage in this document related to the different RTP sessions. Please remember that the most fundamental part of the RTP session definition is that each RTP session has its own SSRC space.

So there is one SSRC number space for the multicast RTP session. An SSRC from this space is used in the Token Verification Request to identify the requesting client. In the Token Verification response message this SSRC identifier is included in the Token response message. The problem is that this message is conveyed in the unicast RTP session that has its own SSRC space. Thus we have potentially create a coupling between the two RTP sessions.

<Tom: well the text says for the "token verification failure message":

SSRC of Requesting Client (32 bits):  Field that contains the SSRC
      of the client who sent the verification request.

..but this does not mean it equals the SSRC in the token verification request message.  The port mapping "client" has its SSRC in the SSM session, its SSRC in the port mapping exchange messages with the server and its SSRC in the unicast sessioon. It needs to use the correct SSRC in the messages sent in all these sessions. Of course, a relaxing implementation may use the same client SSRC across
these sessions.. (but in conflict with RFC 3550)>

As I see it this can be fixed in two ways. Either one explicitly notes that this RTCP Token Response message field carries a value that refers to the SSRC space in another RTP session then one currently are in. 

<Tom: this is what was implied by the text..but should be called out more explictly perhaps>

This is likely the simplest solution.

The alternative is to accept the coupling. But then one has to make clear on how to handle SSRC collisions. This seems problematic as the coupled session is a multicast session. A multicast session has bigger difficulties with changes due to its number of receivers and also that if one forces an active sender to change it may causes widespread disruption.

I also observe that it is not clear what SSRC space the Port Mapping request and response messages uses. Does this need to be synchronized with any other space or can it be its own unique one. A unique one is probably easiest. I don't see any direct coupling to the other sessions.

<Tom: has its own SSRC space....  See also the figure that shows the three sessions decoupled by means of the dashed lines..>

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]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 18:17:56 +0100

> <Tom: this is what was implied by the text..but should be called out more explictly perhaps>

Yes, just being a bit more explict about that this SSRC value are in
another RTP session SSRC space resolve this.

> <Tom: has its own SSRC space....  See also the figure that shows the three sessions decoupled by means of the dashed lines..>

Ok, it is not obvious. And I have to say that this session is far from a
common RTP session. It is only RTCP messages, and also in fact not sent
using normal timer rules. Only when needed, which might actually need to
be pointed out also.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:32:59 -0800

> Sent: Friday, January 14, 2011 5:22 PM

Are you referring to the port mapping request/response messages? In that request, client chooses an SSRC randomly. This exchange does not belong to either session (not necessarily) since the same token can be used in different unicast sessions.

In the token verification request message, the client uses whatever SSRC it needs to use for that particular unicast session.

> own SSRC space. Thus we have potentially create a coupling between the

Nope, this is not correct.
 
> is likely the simplest solution.

This is already mentioned in section 4.1 where we say the ssrc is chosen randomly. 
 
> probably easiest. I don't see any direct coupling to the other sessions.

That SSRC is not used anywhere for a purpose, so that's why we decided to say "choose it randomly and forget about it".

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 11:42:39 +0100

> Nope, this is not correct.

Lets try again to describe the above paragraph, as we clearly
missunderstanding each other.

The client has an SSRC that is uses for regular RTCP feedback to the
Retransmission server. If is want to send a NACK, then it include a
Token Verification Request. In that message it include the SSRC of the
client. This SSRC comes from the Multicast RTP sessions SSRC space.

Then the Retransmission server may send an RTCP message back to the
client in a form of the Token Verification Failure message. This message
include the SSRC of the requesting client. As this Token Verification
Failure message is sent in the RS -> Client leg of the created unicast
session, but is in reality a response to the message in the multicast
RTP session. This creates a case where it is uncertain which SSRC space
the SSRCs in the failure message belong to. Based on network selectors,
e.g. UDP ports this message is in the unicast space. But semantically it
belongs to the Multicast channel.

Please make it clear in the description in 4.4 what space the SSRC
values belongs to.

> That SSRC is not used anywhere for a purpose, so that's why we decided to say "choose it randomly and forget about it".

Yes, for mapping message that is fine. The thing I can complain about is
why the SSRC fields aren't there own bullets and instead hidden in the
pre-facing text to the figures?

-- 

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 05:23:54 -0800

> client. This SSRC comes from the Multicast RTP sessions SSRC space.

Right.
 
> Failure message is sent in the RS -> Client leg of the created unicast

Yes, and the server simply gets this SSRC from the request message. 

> session, but is in reality a response to the message in the multicast

Yes, maybe it was a NACK sent for the multicast session.

> Please make it clear in the description in 4.4 what space the SSRC

In the failure message:

SSRC of Packet Sender: This is server's SSRC, which equals the SSRC of the respective primary multicast stream.
SSRC of Requesting Client: This SSRC is directly copied from the Token Verification Request message (this text already exists in 4.4).
 
Is the "packet sender SSRC" definition fine with you?
 
> pre-facing text to the figures?

We can move them to the bullets. We probably did not so because, they are pretty much part of the baseline format.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 16:15:17 +0100

> Is the "packet sender SSRC" definition fine with you?

I think I would like to have extra warning: "Note, theis SSRC value are
from a different SSRC space than the one used in the Unicast RTP session."

> We can move them to the bullets. We probably did not so because, they are pretty much part of the baseline format.

I think it has its point when we do have some irregularities here in
some cases.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 05:09:38 -0800

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, January 17, 2011 10:15 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [email-masked]
> Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces
> 

OK.

-acbegen