Subject: [Ietf-behave] AD Evaluation of draft-ietf-behave-multicast-02

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Sep 2006 03:44:58 -0500 (CDT) (envelope-from [email-masked])

Hi,

I have done the AD evaluation of this document and do have a few comments.

1. There is a lack of references and explanation of abbreviations. For 
example none of IGMP version talked about in the introduction has any 
references.

2. Section 2:
"Sending multicast traffic is out of scope because it requires NATting
   the source IP address of such transmitted multicast traffic."

This does not motivate why NATing the source would be a problem and thus 
should be done so that the receiving entity can actively participate in 
a session.

3. Section 3.1:
"Hosts will periodically send IGMP Report messages to indicate
   continued interest in receiving the multicast traffic."

I think "hosts" in the above sentence should be clarified to mean the 
NATed hosts.

4. Security consideration.
I think it should reference the MAGMA proxy drafts security 
consideration also.

I would appreciate an update to resolve these comments.

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: "Dan Wing" <[email-masked]>
Date: Mon, 11 Sep 2006 20:46:18 -0500 (CDT) (envelope-from [email-masked])

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@xxxxxxxxxxxx] 
> Sent: Monday, September 04, 2006 1:45 AM
> To: Dan Wing; Behave WG
> Subject: AD Evaluation of draft-ietf-behave-multicast-02
> 
> Hi,
> 
> 1. There is a lack of references and explanation of 
> abbreviations.  For example none of IGMP version talked about 
> in the introduction has any references.

The new version now normatively references IGMPv2 and v3, and
non-normatively referencing IGMPv1 (which is declared out of
scope because it isn't widely deployed).

> This does not motivate why NATing the source would be a 
> problem and thus should be done so that the receiving entity 
> can actively participate in a session.

You're right, and there is no good reason to reduce the scope
and eliminate that functionality.  I removed that sentence from 
the updated version.  I did not see any other impact to expanding
the scope in that manner.

> I think "hosts" in the above sentence should be clarified to mean the 

Done.

> I think it should reference the MAGMA proxy drafts security 

Done.

> I would appreciate an update to resolve these comments.

The new version is at:
http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast
-03.txt

Differences from -02 are at:
http://tinyurl.com/hmyq5

I will wait a day for BEHAVE comment and then post it as an Internet Draft.

Thanks for your review!

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Sep 2006 06:46:45 -0500 (CDT) (envelope-from [email-masked])

Dan Wing skrev:

2. Section 2:

The only issue I have with this change is that there are no requirements 
 on how a NAT should handle outbound traffic to multicast traffic and 
that binding state. I think there will be need for something that 
clarifies that. If I understand things correctly, the NAT needs to 
translate each transmitting host to a unique external IP and port 
compared to any other host on the internal side. And then maintain that 
binding for as long as the host is continuing to transmit IGMP traffic 
to the NAT. But I am no expert on multicast so please consult with more 
knowledge people.

As I see this this is fundamental change that we probably need to do a 
new short WG last call after implementing. If people are not agreeing 
with supporting sending of traffic to multicast groups please speak up 
now.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Sep 2006 19:37:16 -0500 (CDT) (envelope-from [email-masked])

> Sent: Tuesday, September 12, 2006 4:47 AM
> To: Dan Wing
> Cc: Behave WG
> Subject: Re: AD Evaluation of draft-ietf-behave-multicast-02
> 
> Dan Wing skrev:
> > 
> >> 2. Section 2:
> >> "Sending multicast traffic is out of scope because it 
> >>  requires NATting the source IP address of such 
> >>  transmitted multicast traffic."
> >>
> The only issue I have with this change is that there are no 
> requirements on how a NAT should handle outbound traffic to 
> multicast traffic and that binding state. 

The NAT need only do nothing odd if the destination address
is a multicast address (the Class Formerly Known as Class D).
I can add such a statement to the document.

> I think there will be need for something that 
> compared to any other host on the internal side.

Right; that is normal operation and is covered by -behave-nat-udp.

> And then maintain that binding for as long as the host is 
> continuing to transmit IGMP traffic to the NAT. 

I was thinking doing the normal 2 minute timeout, as
described in -behave-nat-udp, would be sufficient.  There
could be two unrelated multicast applications running on one 
host -- one receiving multicast traffic and another one that
sends multicast traffic.  

Similarly, if you have nested NATs (doing NAPT), like this:

   host1-+
         |
   host2-+--NAT1---NAT2---------Internet
         |
   host3-+

NAT2 will only see NAT1.  Host1 might be receiving multicast traffic and
host2 might send to a multicast address, but now NAT2 will keep host2's
outgoing binding open unnecessarily.  Over time, one persistant multicast
listener and occasional multicast senders, all behind NAT1, would consume
all of NAT2's bindings.

> But I am no expert on multicast so please consult 
> with more knowledge people.
> 
> As I see this this is fundamental change that we probably 
> need to do a new short WG last call after implementing. 

Agreed.

> If people are not agreeing with supporting sending of 
> traffic to multicast groups please speak up now.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Sep 2006 02:41:42 -0500 (CDT) (envelope-from [email-masked])

Dan Wing skrev:

   host1-+
         |

Okay, I see the problem. However I don't think a two minute timeout will 
cut it. The reason is that an ASM session with RTP and RTCP  a pure 
listener may transmit less than one RTCP packet every 2 minutes, for 
example 50 kbps of RR and 8000 participants will result in that. The 
example is a large multicast group but not extremely large. The issue 
this result in is that each time a host's binding times out it will 
change source address tuple. This may trigger collision detection in 
other session members, see Section 8.2 in RFC 3550.

Can't we recommend that a NAT keeps the binding for at least 1 hour if 
it receives IGMP traffic. To protect against an attack/exhaustion of 
resource the NAT may close down bindings starting with the longest 
inactive down to them being treated equally to normal UDP ones. That way 
I think we will have good performance and only inconsistent behavior in 
the case of resource exhaustion.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Sep 2006 22:23:38 -0500 (CDT) (envelope-from [email-masked])

...
> Okay, I see the problem.  However I don't think a two minute
> timeout will cut it.  The reason is that an ASM session with RTP
> and RTCP  a pure listener may transmit less than one RTCP packet
> every 2 minutes, for example 50 kbps of RR and 8000 participants
> will result in that.  The example is a large multicast group but
> not extremely large.  The issue this result in is that each time a
> host's binding times out it will change source address tuple.  This
> may trigger collision detection in other session members, see
> Section 8.2 in RFC 3550.
>
> Can't we recommend that a NAT keeps the binding for at least 1 hour
> if it receives IGMP traffic.  To protect against an
> attack/exhaustion of resource the NAT may close down bindings
> starting with the longest inactive down to them being treated
> equally to normal UDP ones.  That way I think we will have good
> performance and only inconsistent behavior in the case of resource
> exhaustion.

Thanks for bringing that to my attention.  You're right, a two minute
timeout won't work.  RFC3550's suggestion that a new SSRC chosen if 
the source transport address changes isn't tenable with a NAPT that 
times out sessions -- an RTP application would need to change its 
SSRC any time two minutes had elapsed between RTP or RTCP 
transmissions or do a STUN check hoping to discover the mapping 
had not timed out.  Either solution is pretty gross.

I rewrote section 3 to accomodate your suggestion and placed the new
version, dated September 13th, at:

http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast
-03.txt
  http://tinyurl.com/gsllh
  (the second URL merely redirects to the first)

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Sep 2006 02:45:25 -0500 (CDT) (envelope-from [email-masked])

Hi Dan,

I have looked at the text you wrote. A couple of comments:

If a
   NAPT followed the requirements of [I-D.ietf-behave-nat-udp] (and
   timed out a UDP session after 2 minutes of inactivity) and the
   multicast group is sufficiently large (approximately 8000 members
   with a normal 50kbps audio RTP stream), the elapsed time between a
   NAPTed host sending its RTCP Receiver Reports would exceed 2 minutes,
   causing an unnecessary RTP collision detection to be performed by
   other session members.

That calculation was done for 50 kbps of RTCP receiver bandwidth, i.e. 
B=RR:50000 in SDP. For the session you specify in text with the normal 
5% (3.75% of session bandwidth to receivers) rules would result in 
deterministic intervals beyond 2 minutes for session of around 300 
participants or more.

   This requires the NAPT not assign a new UDP source port for that
   raffic.

Misspelled "traffic" at the end of the session.

Otherwise it looks good.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Sep 2006 19:00:40 -0500 (CDT) (envelope-from [email-masked])

> That calculation was done for 50 kbps of RTCP receiver 
> bandwidth, i.e.  B=RR:50000 in SDP. For the session you specify in 
> text with the normal 5% (3.75% of session bandwidth to receivers) 
> rules would result in deterministic intervals beyond 2 minutes 
> for session of around 300 participants or more.

Thanks.  Adjusted my text from "8000 members" to "300 members".

> Misspelled "traffic" at the end of the session.

Fixed.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Sep 2006 02:31:32 -0500 (CDT) (envelope-from [email-masked])

Thanks,

Then I am satisfied with the update. Unless someone has any objection I 
will go to IETF last call as soon as the updated version is available.

/Magnus

Dan Wing skrev:

If a
    NAPTed host sending its RTCP Receiver Reports would 
exceed 2 minutes,

Fixed.

-d

--

Magnus Westerlund