Re: [pim] Path MTU support for Multicast

["Nandy, Tathagata" <[e-mail]>]

Thanks a lot Jake for the suggestions, it really helps. I will start looking at the all points that you mentioned and get back on them soon. 

Tathagata

-----Original Message-----
From: Holland, Jake [mailto:[e-mail]] 
Sent: Thursday, April 23, 2020 4:53 AM
To: [e-mail]; Nandy, Tathagata <[e-mail]>
Cc: MBONED WG <[e-mail]>; [e-mail]; [e-mail]
Subject: Path MTU support for Multicast

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