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

[Stephen Casner <casner@xxxxxxx>]

Magnus,

> 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.

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.

> 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.

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.

> 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.

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.

> 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.

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

                                                        -- Steve