Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req

From: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Dec 2010 14:10:27 +0100

Hi,

I looking at the new text and even more on the example I think there is
something about the SDP attribute a=portmapping-req we need to discuss.

Section 7.1 says:

"  This new SDP attribute is used declaratively to indicate the port and
   optionally the address for obtaining a Token.  Its presence indicates
   that a Token MUST be included in the feedback messages sent to the
   server triggering or controlling a unicast session (See Section 4.3
   for details)."

As the messages that the token goes into is the RTCP feedback related to
the multicast stream. Thus I would assume that the portmapping attribute
would actually go into the media block in the SDP that describes the
multicast session and its unicast RTCP feedback. But, according to the
example it goes into the unicast session. I find that strange.
Especially as one of the purpose is to indicate in which RTCP flow the
token needs to be included. To me following the example would indicate
that tokens are to be included in the RTCP directly related to the
unicast session, i.e. reporting on the RAMS burst for example, rather
than in relation to the RTCP message requesting the RAMS burst.

I think there needs clarification on where one puts this attribute.

2. I wonder if one shouldn't explicitly include some indication of what
RTCP messages one expect the token to be included in. We already have a
similar indication in the rtcp-fb attribute. Shouldn't this mechanism be
made part of the portmapping-req attribute to indicate which messages
that needs token?

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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 05:26:30 -0800

On the 1st issue: I remember this coming up at some point (maybe it was you or somebody else). And you are right, the current text in section 7.1 and the example in 7.3 indicate that the 'portmapping-req' goes into the unicast media block (if used at media level).

The reasoning was:
- There could be multiple associated unicast sessions for each SSM session, and in that case specifying this separately made more sense
- The messages we bundle with the Token (such as RAMS-R, RAMS-T, BYE, CCM, etc.) are actually related to the unicast stream not the multicast stream. Well, you could argue that RAMS-R starts the burst for a multicast stream but I could argue that it starts *the* unicast stream. OTOH, RAMS-T directly controls the unicast stream has nothing to do with the multicast, so does the BYE for the unicast session.

Following up on this, for the 2nd question: Tying the token to the rtcp-fb line does not seem much right, either. For example, rtcp-fb line in the multicast media block has nothing to do with RAMS-T.

We tried to be as explicit as possible in section 4.3 and left the door open for future possible additions to the list of messages that require or might require a Token. If that does not look good, we are open to suggestions.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Thursday, December 09, 2010 8:10 AM
> To: IETF AVT WG
> Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req
> 
> Hi,
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Dec 2010 14:48:13 +0100

> - The messages we bundle with the Token (such as RAMS-R, RAMS-T, BYE, CCM, etc.) are actually related to the unicast stream not the multicast stream. Well, you could argue that RAMS-R starts the bu…

I would argue that RAMS should actually include the portmapping-req in
both the unicast and the multicast session as you require it in both
RTCP usages. That I think would be the best way of handling rams. That
would mean an example like this:

        v=0
        o=ali 1122334455 1122334466 IN IP4 rams.example.com
        s=Rapid Acquisition Example
        t=0 0
        a=group:FID 1 2
        a=rtcp-unicast:rsi
        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream
        c=IN IP4 233.252.0.2/255
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
        a=rtpmap:98 MP2T/90000
        a=multicast-rtcp:42000
        a=rtcp:43000 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack rai
	a=portmapping-req:30000 IN IP4 192.0.2.1
        a=ssrc:123321 cname:[email-masked]
        a=rams-updates
        a=mid:1
        m=video 51000 RTP/AVPF 99
        i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux
	a=portmapping-req:30000 IN IP4 192.0.2.1
        a=fmtp:99 apt=98;rtx-time=5000
        a=mid:2

> Following up on this, for the 2nd question: Tying the token to the rtcp-fb line does not seem much right, either. For example, rtcp-fb line in the multicast media block has nothing to do with RAMS-…

I said that the design of the attribute on which RTCP messages requires
token could be done along the lines of the rtcp-fb attribute. Not that
it should be tied to the SDP Attribute. I would say that the portmapping
attribute is related to the RTCP sent for a particular RTP session.
Independent of how that RTCP destination is indicated.

> We tried to be as explicit as possible in section 4.3 and left the door open for future possible additions to the list of messages that require or might require a Token. If that does not look good,…

That is why an explicit indication of what RTCP messages this server
expects to have included a token seems reasonable. Although we need to
have an extensible mechanism that can support any future RTCP messages.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 06:44:27 -0800

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 09, 2010 8:48 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req
> 
> > On the 1st issue: I remember this coming up at some point (maybe it was you or somebody else). And you are right, the
> current text in section 7.1 and the example in 7.3 indicate that the 'portmapping-req' goes into the unicast media block (if
> used at media level).
> >
> > The reasoning was:
> > - The messages we bundle with the Token (such as RAMS-R, RAMS-T, BYE, CCM, etc.) are actually related to the unicast
> stream not the multicast stream. Well, you could argue that RAMS-R starts the burst for a multicast stream but I could argue
> that it starts *the* unicast stream. OTOH, RAMS-T directly controls the unicast stream has nothing to do with the multicast,
> so does the BYE for the unicast session.
> >
> 

I see what you are trying to do here but as I said not all RTCP messages relating to the multicast stream or session need to have a Token. So, having the portmapping-req line in the multicast media block is probably more confusing. 

I am aware that using it only in the unicast media block is not perfect, either, but at least it is more correct and less confusing. Every RTCP message that requires a Token has something to do with the unicast session but not necessarily with the multicast session.

So, I am still inclined to keep the text and example as they are.

Cheers, acbegen.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 20:36:42 -0800

...
> > Following up on this, for the 2nd question: Tying the token to the rtcp-fb line does not seem much right, either. For
> example, rtcp-fb line in the multicast media block has nothing to do with RAMS-T.
> 

Hi Magnus,

We thought of describing the message types needing a Token in the SDP but there is a no clear way of doing this. It seems to be an unnecessary optimization to us, and it will not necessarily simplify the implementation.

First of all, when a client sends a message without a Token (although it was needed), the server will send a " Token Verification Failure" message. If the client implements the Token specification, it will know what to do (will try to acquire a Token). This will cost merely an RTT of delay. And this delay is not necessarily a serial delay. We don't need any further optimization here. If the client does not implement Token stuff, and the server requires it for that particular service, it means the client will not get that service. There is nothing we can do about this.

Second, listing which RTCP packet types (e.g., 204, 205 or 206) require a Token in the SDP description is not straightforward. If simply listing 205 or 206 were enough, we could use this approach. However, it is not. For example, under 205 some FMT values will require a Token while others will not. Furthermore, RAMS defines a sub-FMT field to identify specific RAMS control messages. To indicate that RAMS-R message requires a Token, we would have to say in the SDP "205 (for RTPFB) -> 6 (for RAMS) -> 1 (for RAMS-R)". We don’t think this is a clean approach.

Overall, I think we could keep the current approach where the SDP only carries the 'portmapping-req' attribute to indicate the port/address for Token requests. No need to describe anything further. Section 4.3 seems sufficient.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Dec 2010 10:56:58 +0100

> First of all, when a client sends a message without a Token (although it was needed), the server will send a " Token Verification Failure" message. If the client implements the Token specification,…

Ok, that is actually a point that is pretty strong. However, I would
point out that the RTT you are talking about is the time of sending one
RTCP message in each way. Which is likely substantially longer than the
network layer RTT between the two nodes.

I would like to see clearer text on what future extensions requiring
this functionality needs to define. It appears that they would need to
define what RTCP messages that needs tokens. And taking RAMS as a case,
the need to possibly do it in two sessions.

Which leads me into a question if it is not clearer to signal this
explicitly. For in RAMS we do have the RAMS-R that goes to the RTCP
feedback port in relation to the multicast group. Then we have RTCP BYE
and RAMS-T that goes in the created unicast session. If one combines
this with also retransmission then that goes into the multicast RTCP
feedback flow. Having explicit indication on where all of these goes I
think has its points. Especially when people do extensions and stuff and
may require more than what the basic extension requires.

I also wonder if this can become a point of interoperability. Not that
it in practice is difficult to include the token verification request
together with any other messages, but you need to write your code in a
certain way so that you can do it always, and especially if one gets a
token verification failure on a message you where not expecting it on.
Especially if it is a compound packet with several message types so that
you don't really know.

> Second, listing which RTCP packet types (e.g., 204, 205 or 206) require a Token in the SDP description is not straightforward. If simply listing 205 or 206 were enough, we could use this approach.…

Yes, I agree not straight forward, but clearly possible to do and you
probably can write up a good one in a few hours. As I see it you need to
cover general RTCP packet types of single purpose, some that has
multiple subfields or functionaltity, the APP one and private extensions
(maybe using a reverse domain name system).

> Overall, I think we could keep the current approach where the SDP only carries the 'portmapping-req' attribute to indicate the port/address for Token requests. No need to describe anything further.…

Still disagreeing and would like to hear more input into this question.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 10 Dec 2010 04:52:36 -0800

> Sent: Friday, December 10, 2010 4:57 AM
> > We thought of describing the message types needing a Token in the SDP but there is a no clear way of doing this. It seems
> to be an unnecessary optimization to us, and it will not necessarily simplify the implementation.
> >
> > First of all, when a client sends a message without a Token (although it was needed), the server will send a " Token
> Verification Failure" message. If the client implements the Token specification, it will know what to do (will try to acquire a
> Token). This will cost merely an RTT of delay. And this delay is not necessarily a serial delay. We don't need any further
> optimization here. If the client does not implement Token stuff, and the server requires it for that particular service, it means
> the client will not get that service. There is nothing we can do about this.
> >
> 

Still not necessarily a delay factor since it is not serial if used properly.
 
> > Second, listing which RTCP packet types (e.g., 204, 205 or 206) require a Token in the SDP description is not
> straightforward. If simply listing 205 or 206 were enough, we could use this approach. However, it is not. For example, under
> 205 some FMT values will require a Token while others will not. Furthermore, RAMS defines a sub-FMT field to identify
> specific RAMS control messages. To indicate that RAMS-R message requires a Token, we would have to say in the SDP "205
> (for RTPFB) -> 6 (for RAMS) -> 1 (for RAMS-R)". We don’t think this is a clean approach.
> 
> > Overall, I think we could keep the current approach where the SDP only carries the 'portmapping-req' attribute to indicate
> the port/address for Token requests. No need to describe anything further. Section 4.3 seems sufficient.
> 

Does anybody else think about this strongly one way or another?

-acbegen