Re: [AVT] New Version Notificationfordraft-ietf-avt-ports-for-ucast-mcast-rtp-01

[Jinwei Xia <[e-mail]>]

Hi Ali and Tom,

I agree the majority opinions from Tom.

a) each couple of PMReq and PMRes should be exchanged prior to RTCP message
which solicits a forthcoming unicast RTP session on different destinatioin
port, e.g., one PM round-trip plans to map on P3 for unicast retransmission,
another PM round-trip plans tomap on P4 for unicast burst. If the third
unicast session uses P5 by server and client (client can request multiple
unicast bursts in session multiplexing case through different ports), you
need to perform one more PM round-trip for P5. should we mention this?

In PMReq, client can use its own SSRC in media sender field. Becasue it only
aims to establish port mapping on NAT without any SSRC relevancy.  I perfer
to reuse message format defined in RFC4585 rather than define new message
format header for port mapping messages.

b) I also prefer use same format to carry cookie both on PMReq and PMRes. Is
it fit to reuse NACK message to respond to PMRes? Or define a new PMNack
message (FMT=9) just like PMReq and PMRes? Otherwise, what's the values
setted in the PID and BLD field in NACK? Another point, sending NACK to P3
seems to be illogical from whole round-trip integrality point of view.

c) I agree to use SSRC to indentify the client in order to link unicast
session and SSM session.

d) In security considerations, I don't understand how to use CNAME to aviod
cookie stealing in non-compound RTCP message.


BR
Jinwei

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> VAN CAENEGEM Tom
> Sent: Thursday, April 15, 2010 8:12 PM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); IETF AVT WG
> Subject: Re: [AVT] New Version
> Notificationfordraft-ietf-avt-ports-for-ucast-mcast-rtp-01
> 
> Hi Ali,
> 
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[e-mail]]
> Sent: dinsdag 13 april 2010 15:28
> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); IETF AVT WG
> Subject: RE: [AVT] New Version Notification
> fordraft-ietf-avt-ports-for-ucast-mcast-rtp-01
> 
> Hi Tom,
> 
> Thanks for the quick review.
> 
> > a) The figure 3, which I believe is intended to be a
> general figure,
> > may be misleading in the RAMS case, as there will not be
> any SSM RTP
> > packet flow prior to the port mapping message exchange. So the 
> > possible absence of the SSM prior to the port mapping
> messaging should
> 
> > be explicitly mentioned IMO
> 
> Good point. Maybe, we should provide two figures? Or just focus on the 
> RAMS scenario since the retransmission is a subset?
> 
> TOM: the figure should be made generic IMO, where you draw both the FT 
> entity and the Burst/Retransmission Source entity entity as two 
> separate disjoint vertical lines. Replace "retransmission" with 
> "unicast session RTP", NACK with FB, etc..
> 
>  
> > If the SSM flow is not present yet, we will probably need
> to define a
> > rule on how the RTP receiver needs to fill out the "media
> sender SSRC"
> > field in the port mapping FB message (you ask this same question I 
> > believe in the draft). This bears some similarities with
> what we did
> > for RAMS-R in the RAMS draft, but is still different. As the SSRC 
> > identifier has no specific meaning here (it is not used or
> parsed in
> > the port mapping and cookie generation process), I think it
> is OK to
> > say that the RTP receiver puts its own SSRC in this field. This is 
> > aligned with what was specified for RAMS-R.
> 
> The assignment of media sender SSRC in the PM request message is a bit 
> tricky as it was in the RAMS. If there are no objections, we can go 
> with Tom's proposal but what about the retransmission case where the 
> client would know the media sender SSRC before asking for the cookie. 
> Should we still set the media sender SSRC field to client's SSRC?
> 
> TOM: we better have a clear single rule here. The SSRCs are not 
> relevant in the port mapping process (unless I overlook something?). 
> We need to be clear also on how the media sender SSRC and packet 
> sender SSRC are set in the port mapping response messages. As opposed 
> to the RAMS-I in a multi SSRC use case, we need only one port mapping 
> response, but which media/packet sender SSRC to use when there are 
> multiple SSRCs in the SSM? The feedback message is not the best format 
> here.
> Perhaps you need to define new message format header for port mapping 
> messages, w/o SSRC fields (but that can still be sent ASAP, as with 
> AVPF profile)
>  
> > In the figure 3, the session between burst/retransmission source 
> > entity of the RS and the RTP receiver is established after the NACK 
> > (or RAMS-R, or whatever future app message that will be defined), 
> > ....but is the session not established when the port mapping request
> is sent out first?
> > It uses the same transport addresses.
> 
> I believe the session is established upon receiving a nack, rams-r, 
> etc.
> since the server will not allocate resources before it receives such 
> messages. The previous one is just a cookie request. And at that time, 
> it is not clear when the client will actually use it or not.
> 
> TOM: if people agree on this, we need explicit text on this in the 
> port mapping draft, e.g. the unicast RTO session is establised when 
> the RTP receivers send the 1st RTCP message to the RS with the cookie 
> . E.g. no SR should be sent by the RS in the unicast session prior to 
> reception of this 1st RTCP message.
>  
> > b)You did not define how the cookie is transported from RTP
> receiver
> > to the RS (message format?)
> 
> Yeah, looks like we missed it. Could we use the PMRes format for this?
> Or, should we define a separate format for this? 
>  
> TOM: one format that fits both PMReq and PMR as well as cookie is 
> possible IMO.
> 
> 
> > c)The main reason why the alternative port mapping without
> cookie, as
> > presented in Anaheim, was no longer considered,  is because RTCP 
> > messages sent out by an RTP receiver in the SSM session and RTCP 
> > messages in the unicast RTP (retransmission) session cannot
> be linked
> > with one another, when there are multiple receivers behind
> a NAT. The
> > same issue is still present here. Solutions are:
> > 
> > -mandating that the "packet sender SSRC" of the RTP receiver is the 
> > SSM session is the same as the "packet sender SSRC" used by
> the same
> > RTP receiver in the associated retransmission session. SSRC
> collisions
> 
> > for
> 
> Actually, I don't see why the client would use different packet sender 
> SSRCs when sending feedback/reports in the SSM session and in the 
> unicast session. Since they are considered different sessions, I do 
> not see a reason to use different values provided that the rtcp ports 
> on the server for the SSM and unicast sessions (P3 and P4) are 
> different.
> 
> TOM: they are two different sessions, so an RTP end-point can (and
> should) generate a random SSRC value in both sessions (RFC 3550). I 
> would propose that we mandate the two SSRC values to be the same for 
> those applications making use of portmapping.
> Q: do you allow P3 and P4 to be the same? This should not be made 
> possible as it does not allow the RS in a straightforward way to link 
> the incoming RTCP (RR) with the right session!
> 
> > those RTP receivers behind the same NAT can then be
> resolved with an
> > RTCP RSI message (to be transmitted by the DS!). BTW, this
> also causes
> 
> > the non-cookie approach to work in all circumstances..
> 
> If two clients behind the same nat end up using the same SSRC, the 
> CNAMEs can be used to separate the reports. At the end if all fail, 
> the reported values might be wrong but port mapping will should work.
>  
> > -having the cookie sent along with every RTCP message, sent
> either in
> > the SSM session (to the FT entity) or in the unicast session. This
> 
> This will require every client to get a cookie whether or not they 
> need a unicast session, right? Cookie should be used only if there is 
> a need for a unicast session (meaning that all feedback messages 
> establishing a unicast session
> (nack/rams-r) need the cookie).
> 
> > actually augments the functionality of the cookie: it is
> also used as
> > a unique identifier (in other words it maps one-to-one with an RTP 
> > receiver), and the information hashed in the cookie
> provides  to the
> > RS the transport address for the unicast (retransmission) session 
> > RTP/RTCP packets, when the received RTCP message triggers the RS in 
> > sending RTP/RTCP packets in this unicast session.
> 
> Using the cookie in RTCP reports might be overkill, don't you think?
> 
> TOM: sure, it is not ideal, but you need a way to make sure that the 
> RTCP reports received in the two sessions can be linked to the same 
> RTP receiver by the RS. Having same SSRC is the better solution. 
> Making CNAMES really unique is also an option, but then the FB 
> messages must be sent as compound RTCP messages.
> 
> > 
> > Editorial comments:
> > 
> > 1) In the figure 2, it would be better to include the FT and 
> > Burst/Retransmission Source sub-entities, as part of the 
> > Retransmission server (RS). I understand the figure/example
> is about
> > retransmissions, but the RAMS is the more complex example,
> where for
> > instance there are also feedback rtcp reports sent to the
> Burst Source
> entity on port P4.
> > The figure only mentions feedback messages on port P3. This
> is indeed
> > true for retransmission, but making the more generic figure that 
> > addresses RAMS as well, would be more informative IMO.
> 
> OK.
>  
> > 
> > 2) section 3:
> > "Port P3 denotes the RTCP port on the feedback target running on
> >       the retransmission server to collect the RTCP
> feedback messages,
> >       and RTP receiver and extended reports from the clients in the
> >       primary multicast session.  Port P3 is defined declaratively."
> > 
> > Typo: ... and RTCP receiver and extended reports..
> 
> Will fix.
>  
> > 3) section 3.1
> > 
> > "The client determines its receive port numbers (*c1 and *c2)."
> > 
> > Is the term "receive port" for c1 not strange and confusing
> as the RTP
> 
> > receiver does not receive anything on this port, as it only
> transmits
> > on this port...
> 
> Good catch, will fix this, too.
> 
> -acbegen
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt