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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Oct 2006 04:26:46 -0500 (CDT) (envelope-from [email-masked])

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: magnus.westerlund@xxxxxxxxxxxx

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Oct 2006 09:21:27 -0500 (CDT) (envelope-from [email-masked])

Mark Baugher skrev:

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

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: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Oct 2006 03:37:42 -0500 (CDT) (envelope-from [email-masked])

Mark Baugher skrev:

Magnus,

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

Mark Baugher skrev:

Magnus,

Mark

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.

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: Mark Baugher <[email-masked]>
Date: Wed, 4 Oct 2006 09:04:09 -0500 (CDT) (envelope-from [email-masked])

Magnus,

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

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.

Cheers

Magnus Westerlund

_______________________________________________
Audio/Video Transport Working Group
avt@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Wed, 4 Oct 2006 16:57:26 -0500 (CDT) (envelope-from [email-masked])

Magnus,

Mark Baugher skrev:

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

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.

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

Cheers

Magnus Westerlund

---

From: Stephen Casner <[email-masked]>
Date: Thu, 5 Oct 2006 13:14:05 -0500 (CDT) (envelope-from [email-masked])

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