Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]

["Ali C. Begen (abegen)" <[e-mail]>]

Inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Thursday, December 02, 2010 8:59 AM
> To: Ali C. Begen (abegen)
> Cc: Colin Perkins; IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]
> 
> Hi,
> 
> My views on some of these comments
> 
> Ali C. Begen (abegen) skrev 2010-12-02 02:56:
> 
> >> - Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It
> may
> >> be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is
> >
> > Yes, reworded as requested.
> >
> >> used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for
> >> other RTP sessions until the expiration time of the tokens issued?
> >
> > Not sure why we would need this.
> 
> I think this is actually an interesting aspect of this. The draft seems
> to be missing text on the issues of re-using a unicast session for
> another usage. And here I think there are several aspects of this.
> - Reusing a unicast session for different type of RTCP requests (which
> may work

This is not a problematic case.

> - Reusing a unicast session for different multimedia session, which I
> think implies having them share the FTap.

This is not a problematic case, either.
> - Reuse over time of the port for different services. (which is the one
> I think Colin was going after).

OK, this is interesting. Lets discuss it. Remember that the PT port (server side) is advertised in the SDP at media or session level.

If advertised at the media level, PT is the port where the clients (who plan to start that particular unicast session with the server) send their token request message. This is illustrated in the SDP example in the draft.

If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the server(s) and clients. Recall that existence of the 'portmapping-req' attribute indicates that a Token is required for all unicast sessions. Note that different unicast session may have different server addresses, the attribute above only indicates the common port for them.

Maybe, we should add the following SDP example to the draft. Here there are two SSMs with unicast feedback (4 "m" lines), the 'portmapping-req' is used at the session level. Each SSM has a different feedback target address.

        v=0
        o=ali 1122334455 1122334466 IN IP4 nack.example.com
        s=Local Retransmissions
        t=0 0
        a=group:FID 1 2
        a=group:FID 3 4
        a=rtcp-unicast:rsi
        a=portmapping-req:30000
        m=video 41000 RTP/AVPF 98
        i=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:41500
        a=rtcp:42000 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=mid:1
        m=video 42000 RTP/AVPF 99
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                            
        a=rtcp:42500
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:2
        m=video 51000 RTP/AVPF 98
        i=Multicast Stream
        c=IN IP4 233.252.0.3/255
        a=source-filter:incl IN IP4 233.252.0.3 198.51.100.2 
        a=rtpmap:98 MP2T/90000
        a=multicast-rtcp:51500
        a=rtcp:52000 IN IP4 192.0.2.2
        a=rtcp-fb:98 nack
        a=mid:3
        m=video 52000 RTP/AVPF 99
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.2
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                            
        a=rtcp:52500
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4 
 
I also added the following to the SDP section for the 'portmapping-req' attribute:

" If used at a media level, the attribute MUST be used for a unicast media stream."

> >> - Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the
> RTCP
> >> BYE packet need this?
> >
> > I don’t think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.
> >
> 
> Ali, don't BYE also need it at least in the RAMS case? There a BYE
> message stops all bursts.

You are right. Somebody else may prematurely end your burst. This is true even in normal retransmission scenarios.
 
> I would say anyone that has any type of control function.

Right.
 
> > There could be some future packet formats or message types that might require a Token. How could we word this better?
> Any ideas?
> 
> I would divide them up into 3 categories:
> 
> 1. The ones that needs a special unicast session to work.
> - NACK
> - RAMS-R
> 
> 2. Control messages that could use the verification that they are
> comming from whom we previously has communicated with at this IP address.
> - CCM messages
> - RTCP Bye

These are the BYEs sent for the unicast sessions not multicast sessions which we do not need to use Token for. Agree?
 
> 3. Reports etc that no direct impact, although secondary impact can be
> present.
> 
> I do note that stronger source authentication mechanisms should be
> considered in all these cases.

Thanks, will change the text accordingly.

-acbegen