Subject: [Ietf-behave] multicast-04: need WG discussion

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Oct 2006 20:20:32 -0500 (CDT) (envelope-from [email-masked])

(As individual contributor)

I rewrote the BEHAVE multicast document, which was just announced.  The
changes are based on a brief discussion on the AVT mailing list:
  http://www1.ietf.org/mail-archive/web/avt/current/msg07273.html
  http://www1.ietf.org/mail-archive/web/avt/current/msg07282.html
and based on comments I received from other reviewers.

The change is significant:  the document only places one requirement on NATs
that support any-source multicast and have hosts that send traffic into the
same multicast group (requirement reproduced below).

And that is it.  The document says nothing else of substance.  With the
existance of RFC4605 on IGMP/MLD Proxying, I feel -- as an individual
contributor -- that there is little value in the BEHAVE multicast document
and we should consider removing it from our milestones.

Comments?

-d

-----

http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-04.txt

   3.  Extend Mapping Timer for ASM Traffic

   If a NAPTed host is receiving any multicasts stream, and that NAPTed
   host sends UDP traffic to the same multicast address the NAPTed host
   is receiving, the NAPT MUST have a UDP mapping timer of 60 minutes.
   If a NAPT has exhausted its resources, the NAPT MAY time out a
   mapping before 60 minutes have elapsed.  However, a NAPT is still
   required to follow the minimum mapping duration (REQ-5 of
   [I-D.ietf-behave-nat-udp]).

   Discussion: RTP [RFC3550] uses the source transport address (source
   IP address and source UDP port), in addition to the the RTP/RTCP SSRC
   value, to identify session members.  If a session member sees the
   same SSRC arrive from a different transport address, that session
   member will perform RTP collision detection (section 8.2 of
   [RFC3550]).  If a NAPT merely followed the requirements of
   [I-D.ietf-behave-nat-udp] and timed out a UDP session after 2 minutes
   of inactivity and RTCP receiver reports are sent less often than
   every 2 minutes, RTP collision detection would be performed by other
   session members sharing the same SSRC, complicating diagnostic tools.
   This situation can occur, for example, with a multicast group of
   approximately 300 members with a normal 50kbps audio RTP stream.

   To prevent this unnecessary RTP collision detection by other session
   members, the other session members need to see the same source
   transport address for the RTP and RTCP traffic from the NAPTed host.
   This requires the NAPT to assign the same UDP source port for that
   RTCP traffic.  This requirement also facilitates other, non-RTP
   multicast applications which may function similarly.

(During editing and review of this document, several prople asked about
source-specific multicast and wondered why it doesn't have a similar
requirement.  I explain this in the document as well, but this may not be
appropriate in the final version of the document:)

   4.  Considerations for Source-Specific Multicast (SSM)

   There are no special requirements on a NAPT when NAPTing Source-
   Specific Multicast [RFC4604] traffic.  This is because with SSM, the
   RTCP feedback traffic from a NAPTed host is sent to a unicast address
   and [I-D.ietf-avt-rtcpssm] encourages SSM applications to not rely
   exclusively on transport address for collision detecti

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Oct 2006 03:55:04 -0500 (CDT) (envelope-from [email-masked])

Hi,
(As Individual)

I think it would be a mistake to scrap this document. Multicast is 
seeing more and more actual usage, especially in local access networks. 
One such application is IPTV, where the IPTV top-set box preferably can 
work across your home NAT. Also I don't share your thinking that RFC 
4605 will be sufficient. I think it is important to include in the 
BEHAVE series of document to also discuss the need to have a IGMP Proxy 
in the NAT. In addition I think the single hard requirement included 
within this specification is fully sufficient for publishing this document.

A few comments on the document.

1. Why did you remove the formulation that a RFC 4605 was mandated to be 
supported.

2. In section 3:

"   To prevent this unnecessary RTP collision detection by other session
   members, the other session members need to see the same source
   transport address for the RTP and RTCP traffic from the NAPTed host.
   This requires the NAPT to assign the same UDP source port for that
   RTCP traffic.  This requirement also facilitates other, non-RTP
   multicast applications which may function similarly."

I think the second sentence is wrong and confusing: "This requires the 
NAPT to assign the same UDP source port for that RTCP traffic." Although 
RTP and RTCP should have the same source IP address, they shall not 
share UDP port. If they are sent on different ports from the internal 
host, they should go out on separate ports.

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