[MBONED] Path MTU support for Multicast

["Holland, Jake" <[e-mail]>]

Hi Tathagata,

Thanks for bringing this work to the IETF, I think it's a potentially
important problem to address.

I hadn't seen the link to the draft previously, and didn't see it in the
slides during the pim presentation, but eventually found it here and took
a look:
https://tools.ietf.org/html/draft-nandy-singla-utkarsh-pim-mcast-path-mtu-00

I'm writing to suggest a slightly different approach that might be more
widely applicable and easier to deploy quickly, and could potentially
work across overlay networks or various kinds of tunneling, as well as
just within a specific PIM domain.

The background reading is this:
https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-19

And the idea for applying this to multicast is that a sender would send a
defined and paced pattern of probe packets to a well-known SSM group
address (from the 232.0.0.0/24 and ff3x::/32 spaces assigned to IANA in
RFC 4607).

A sender offering this service would simply continue running this stream
all the time (or perhaps stop or cut over to a smaller pattern under more
dangerous conditions, like if it gets a lot of ICMP responses).  But the
defined patterns of traffic would ideally be kept to a reasonably small
flow, to the extent possible, under the assumption that this stream would
be dedicated to MTU discovery, and would be joined by receivers that
actually want some different content from the same source, but are
explicitly checking the MTU for safety.

The detection algorithm would then run entirely on the receiver side
without acknowledgements, and the results would be used as the expected
PMTU for other traffic from the same source IP to that same receiver.

The receiver could then use that PMTU information for the path from that
sender to respond in a variety of ways, depending on the application's
use case.  (For instance, in some applications, it might be appropriate
to send a signal so that senders reduce the MSS for their traffic, but for
other cases the receiver might just determine it's not able to receive a
certain set of traffic, and thus should avoid joining an (S,G), or some
senders might provide the same content with different MSS to support
different PMTU sizes, and the receiver could choose which to join based
on the detected value.)

I had a very brief hallway conversation with Tom Jones about this idea
sometime last year or so, and IIRC the 10-second initial review was "that
sound really cool", but I haven't followed up yet and I don't know
whether it will turn out to be viable.

But with that said, if you're interested enough to work on this problem,
I encourage you to reach out to him and the other authors of
draft-ietf-tsvwg-datagram-plpmtud to see how well it holds up if you try
to flesh out to its full extent the idea of applying a similar concept
in multicast.

It's probably not too hard to write a reference sender and receiver
implementation, although there are probably some tricky details about
exactly what the pattern of probes should be, and maybe some dangers to
watch for if it triggers ICMP responses too routinely.  But if, after
some testing, it seems to get the job done in some useful environments
and doesn't seem too dangerous to run in practice, I certainly would be
supportive for adoption and standardization of the technique.

It was my intention, if I ever got around to it, to bring the idea to
mboned and/or tsv at some point when I could get to it, but I had a whole
long list of things to get to first, and am not done with them yet.  But
if you were able to get this going in parallel, I would be supportive and
happy to see it happen, and would hope to see support from others as well,
if the concept holds up to scrutiny (or constructive feedback if it
doesn't).

I hope that's helpful.

Best regards,
Jake