Subject: [tsvwg] Some comments on draft-shepherd-multicast-udp-guidelines-01.txt

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 08 Jul 2013 10:04:53 +0100

Greg,

I like the idea of publishing something on the topic in this draft, and 
think this a valuable addition to what is said in RFC 5405. It's not 
that multicast is hard - it's just slightly different.

However I do see the need for additional/different congestion control 
requirements for multicast.  Was that the intention, and that the basic 
guidance for using UDP in RFC 5405 also applies?  - I'd have expected 
that RFC 5405 is normatively cited as a list of basic UDP requirements?

This email was as a TSVWG contributor, I'm interested in multicast 
transport/infrastructure (not as a WG Chair).

Gorry

---

Introduction:
I suspect any advice also applies to use of UDP-Lite with multicast?

---

At the end of section 2.1 I see the assertion here that multicast 
tunnels should not be congestion-controlled, making this the 
responsibility of applications that use the tunnels.

While I can see this has been the case with traditional tunnels, the key 
question that needs to be thought about here (I think raised by Magnus?) 
is whether this is right also for automatic multicast tunnels - or 
whether a circuit-breaker approach, as discussed for example with PW3E, 
is more appropriate.

I'm not sure if the IETF should simply ignore protocols designed for 
"private" well-managed networks. For unicast, such traffic now 
frequently traverses VPNs and tunnels via the general Internet. Good 
advice is important, although we may of course be unable to place 
"requirements".

As above for both unicast and multicast, I think the issue here is that 
if the "private" traffic is not CC'ed then the tunnels between private 
networks do not use CC. This then means that we need to think about how 
to protect the unicast CC traffic from this impact. Is this a network 
operational responsibility (e.g. alarms and rate limits) or a transport 
responsibility (e.g. circuit-breakers and CC)?

As I recall, the aggregate multicast tunnel traffic may be argued to 
result in a significant proportion of the internet traffic through a 
home gateway. This question therefore seems relevant to various drafts 
including: AMT and draft-ietf-pwe3-p2mp-pw-requirements-02.txt !!!

---

The multicast congestion control space faces similar challenges to the 
multicast reliability space.

I think the solution space is slightly bigger than the present draft 
says. To me, the key issue with Multicast in the General Internet is 
that there are (at least) three fundamental differences:

* The multicast tree is often not heterogeneous - this implies there may 
be a wide range of path characteristics. This has implications on the 
methods used for RMT e.g. in 3.1 of RFC 5405, it says many applications 
"cannot maintain a reliable RTT estimate for a destination". This often 
applies to the set of destinations in an RMT session or a multicast RTP 
session.

* The heterogeneity also means that some receivers may be receiving 
significantly more loss than the rest of the group. In talks on 
multicast I've called these "crying babies" (by which I mean recipients 
that can gain the attention of the sender and may need special care). It 
seems to me that many multicast apps try to exclude these from the group 
- e.g. start a unicast session to this particular endpoint, or simply 
don't distribute a security key to these receivers.

* Any receiver *anywhere* can potentially try to receive any group. 
That's not a transport problem. It may imply the need for rate limits on 
the aggregate multicast service, but there is no way at the transport 
layer to stop a join message propagating to the next hop router. It also 
points to the need for multicast operators to monitor their 
infrastructure (which we do, and I'm sure others do - since specific 
multicast transport issues can only be debugged when you understand the 
health of the underlying network infrastructure).

While all this may initially seem problematic, the overall goal of 
multicast is for users to get useful data. This implies there is an 
incentive for apps to not to do silly things that will render their 
service useless.

---

Effective MTU: I saw Lars' comment on path MTU discovery (relating to 
3.2 of RFC 5405) - somehow this needs to be combined with the 1200 byte 
rule of thumb that many of us have been using for multicast for years.

I recall some multicast deployments shying away from using PMTUD because 
it was hard to protect the infrastructure when there was no specific 
destination endpoint. Hence this was a DoS vulnerability. (Just because 
a receiver can see a packet from a multicast tree doesn't mean it should 
be allowed to drive-down the sender MTU to a trivial value). Could the 
draft explain whether this is an issue or non-issue?

---

Security

See above on the responsibility for sharing the limited capacity 
available in a typical home gateway.

One of the great things about multicast is RPF checks - a great way to 
protect from some DOS attacks. RPF checks in multicast REALLY help to 
make this manageable!

IPsec and other security mechanisms work with multicast - but they need 
multicast key management techniques.

Maybe the draft should say something about firewalls - pointing them to 
support multicast!

---

NITS

I suspect you do not need to cite this? 
[I-D.narten-iana-considerations-rfc2434bis].

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 10 Jul 2013 18:00:17 -0700

Not wanting to speak for Greg, but i think the reason for the
document is to summarize that IP multicast traffic can pefectly well comply with
Internet congestion control requirements, and that there are a bunch of documents
that explain how.

I have no strong opinion on the process, so 5405 could be normative or informational,
i guess personally speaking i'd certainly hope that its clear that ALC based
rate control is in general better than sender-rate control for Internet multicast,
so everything worked out by RMT and referred to by Gregs doc would in general
superceed the unicast centric 5405. That's how i would read those documents and
resolve conflicts between them.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!