Subject: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Oct 2006 11:25:06 +0200

Hi,

During the IETF last call for "Multicast Requirements for a Network 
Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some 
issues have come up. They all evolve about the binding that a NAT needs 
to create when a host on the inside of the NAT sends traffic either to 
the multicast group or to a feedback receiver in SSM (such as in 
draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP 
and its collision detection mechanism.

draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding 
shall be kept alive for at least 2 minutes. However for a certain amount 
of participants and a given RTCP bit-rate the RTCP reporting interval 
will become longer than the minimum binding lifetime. In those cases 
there is the risk that each message sent will have a different source IP 
address and UDP port tuple. That can trigger the RTP collision detection 
mechanism as described in section 8.2 of RFC 3550.

To avoid these issue in most cases when transmitting to ASM multicast 
groups we propose that NAT will keep bindings for 1 hour. To clarify 
that means no change to the bindings going to unicast addresses, only 
packets that has a multicast group as destination address. The collision 
issue may now occur for sessions that has average RTCP reporting 
interval that is longer than 40 minutes instead of 80 seconds. We 
understand that this will not resolve the issue for sessions that would 
like to run in this configuration.

For SSM sessions it would be best if the feedback receiver and media 
receivers primarily looks at the CNAME for determining SSRC collision 
and not network addresses. This seems necessary anyway for the media 
receivers in simple feedback mode as all RTCP packets will seem to come 
from the distribution source, thus address checking is useless. 
Collisions can only be found by checking the CNAME. In fact I think this 
is something that is required to be clarified in draft-ietf-avt-rtcpssm 
or otherwise all receivers will constantly detect collisions with there 
own RTCP packets.

In the RTCP SSM summary mode the situation is somewhat different. For 
the feedback target, the address would be useful for determining that 
RTCP packet arrives from different sources. However in the presence of 
NATs this becomes a source of error.  I wrote primarily look at CNAME in 
the previous paragraph. The reason for this is the remaining issue of 
loop detection. If one completely skips using the source address one 
will can't determine if some packets constantly comes back from another 
address and actually should be blocked for that reason. Here I don't 
have any brilliant ideas on how to resolve this issue.

Please comment on the proposal

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Wed, 4 Oct 2006 07:03:55 -0700

Magnus,
   I am unclear why we need to address this topic at all.  I don't  
understand why we need to support a napt for multicast.  I'd like to  
understand this basic requirement.

Mark
On Oct 4, 2006, at 2:25 AM, Magnus Westerlund wrote:

> Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03)  
> some issues have come up. They all evolve about the binding that a  
> NAT needs to create when a host on the inside of the NAT sends  
> traffic either to the multicast group or to a feedback receiver in  
> SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here  
> is in relation to RTP and its collision detection mechanism.
>
> draft-ietf-behave-nat-udp does specify that outgoing UDP NAT  
> binding shall be kept alive for at least 2 minutes. However for a  
> certain amount of participants and a given RTCP bit-rate the RTCP  
> reporting interval will become longer than the minimum binding  
> lifetime. In those cases there is the risk that each message sent  
> will have a different source IP address and UDP port tuple. That  
> can trigger the RTP collision detection mechanism as described in  
> section 8.2 of RFC 3550.
>
> To avoid these issue in most cases when transmitting to ASM  
> multicast groups we propose that NAT will keep bindings for 1 hour.  
> To clarify that means no change to the bindings going to unicast  
> addresses, only packets that has a multicast group as destination  
> address. The collision issue may now occur for sessions that has  
> average RTCP reporting interval that is longer than 40 minutes  
> instead of 80 seconds. We understand that this will not resolve the  
> issue for sessions that would like to run in this configuration.
>
> For SSM sessions it would be best if the feedback receiver and  
> media receivers primarily looks at the CNAME for determining SSRC  
> collision and not network addresses. This seems necessary anyway  
> for the media receivers in simple feedback mode as all RTCP packets  
> will seem to come from the distribution source, thus address  
> checking is useless. Collisions can only be found by checking the  
> CNAME. In fact I think this is something that is required to be  
> clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will  
> constantly detect collisions with there own RTCP packets.
>
> In the RTCP SSM summary mode the situation is somewhat different.  
> For the feedback target, the address would be useful for  
> determining that RTCP packet arrives from different sources.  
> However in the presence of NATs this becomes a source of error.  I  
> wrote primarily look at CNAME in the previous paragraph. The reason  
> for this is the remaining issue of loop detection. If one  
> completely skips using the source address one will can't determine  
> if some packets constantly comes back from another address and  
> actually should be blocked for that reason. Here I don't have any  
> brilliant ideas on how to resolve this issue.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Oct 2006 16:21:19 +0200

> understand this basic requirement.

The task of the BEHAVE WG is to try to move to a world where NAPTs 
behave in a more deterministic behavior. In that scenario multicast 
can't be excluded, especially today when we start seeing more and more 
deployment (at least on local scale) of multicast. For example to 
support IPTV.

This is a chartered and milestoned work of the BEHAVE WG.

Cheers

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Wed, 4 Oct 2006 14:57:00 -0700

Magnus,

On Oct 4, 2006, at 7:21 AM, Magnus Westerlund wrote:

>> understand why we need to support a napt for multicast.  I'd like  
>> to understand this basic requirement.
>> Mark
>
> can't be excluded, especially today when we start seeing more and  
> more deployment (at least on local scale) of multicast. For example  
> to support IPTV.
>

Maybe it's obvious, but there is no re-writing of the destination  
address to a unicast or multicast administratively-scoped address.   
The rewriting occurs only on the source address of an outgoing  
multicast packet.  This was not immediately obvious to me.

Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Oct 2006 10:37:31 +0200

Mark Baugher skrev:
> address to a unicast or multicast administratively-scoped address.  The 
> rewriting occurs only on the source address of an outgoing multicast 
> packet.  This was not immediately obvious to me.
> 

Exactly, the issue is that for a RTCP receiver outside of the NAT the 
source address tuple of any RTCP packet received may change due to 
bindings timing out between each transmission from the NATed sender.

Cheers

Magnus Westerlund

---

From: Stephen Casner <[email-masked]>
Date: Thu, 5 Oct 2006 11:13:44 -0700 (PDT)

Magnus,

> mechanism as described in section 8.2 of RFC 3550.

One of the changes from RFC 1889 to RFC 3550 was the following:

   o  In Section 8.2, the requirement that a new SSRC identifier MUST be
      chosen whenever the source transport address is changed has been
      relaxed to say that a new SSRC identifier MAY be chosen.
      Correspondingly, it was clarified that an implementation MAY
      choose to keep packets from the new source address rather than the
      existing source address when an SSRC collision occurs between two
      other participants, and SHOULD do so for applications such as
      telephony in which some sources such as mobile entities may change
      addresses during the course of an RTP session.

Thus, it seems that the "MAY" clauses allow the address change to be
tolerated without any additional mechanism.  It is an open question
whether existing receiver implementations will behave this way.

> like to run in this configuration.

Adding that requirement seems reasonable and useful to me.  Since the
number of ASM multicast sessions is likely to be small, that should
not cause significant resource conflicts for the NAPT.

> or otherwise all receivers will constantly detect collisions with there

Regarding the last sentence, a participant would not receive its own
SSRC with two different addresses, but you are right that it might
consider the receipt of its own reflected RTCP packets as a
collision.  It is worth a note in draft-ietf-avt-rtcpssm.

> have any brilliant ideas on how to resolve this issue.

I don't have any suggestions either, other than eliminate NAT.  :-)

                                                        -- Steve