[pim] Path MTU support for Multicast

"Holland, Jake" <jholland@akamai.com> Wed, 22 April 2020 23:23 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1B70C3A0D5B; Wed, 22 Apr 2020 16:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c575pqbd2ScE; Wed, 22 Apr 2020 16:23:09 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DD33A0D29; Wed, 22 Apr 2020 16:23:09 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net []) by m0050095.ppops.net-00190b01. ( with SMTP id 03MNIQiW002848; Thu, 23 Apr 2020 00:23:02 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=C0pi7lAhxzcnxBopegpGotzDpmPn0dvSu0hvxhVRf/g=; b=JsM7E698Ykb+nDz7+VyJSGOT6f1MS4hQYPxY3ryjkqIJ0Qw5ZNI5e5EfwFxkDIYdG+UT gyvbDn7kER8z/qwAE4nADNZtJdvn2v/N6pn+0fvqXkOTsOWDyy163a79NFc+5kTYRoRN R/v1N7QaP4nAOOfNQgc8/gTV35ypuhw1a1nzweyRhEt4F4pYCf8qtOj4T9Q0zJuwpa2K 8tHHvL0kITA7Jvmx8MktZCOPXeaA2tmQqSd7eG2Pqq7jalh9howAWSq3A/6CQ2eqlMqt RuEbsI0yRlaWGMcuTN+FAtbARRGD7qKOzdUyR1v2jGdHIk2SIZo/CjDTXbp1ssgi5Nl2 kA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 30fs35b65k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 00:23:02 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com []) by prod-mail-ppoint1.akamai.com ( with SMTP id 03MNHYjf025895; Wed, 22 Apr 2020 19:23:01 -0400
Received: from email.msg.corp.akamai.com ([]) by prod-mail-ppoint1.akamai.com with ESMTP id 30fvvw67rk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 19:23:00 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ( by usma1ex-dag1mb6.msg.corp.akamai.com ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Apr 2020 19:22:56 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([]) by usma1ex-dag1mb6.msg.corp.akamai.com ([]) with mapi id 15.00.1497.006; Wed, 22 Apr 2020 19:22:56 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: "pim@ietf.org" <pim@ietf.org>, "tathagata.nandy@hpe.com" <tathagata.nandy@hpe.com>
CC: MBONED WG <mboned@ietf.org>, "tom@erg.abdn.ac.uk" <tom@erg.abdn.ac.uk>, "draft-ietf-tsvwg-datagram-plpmtud@ietf.org" <draft-ietf-tsvwg-datagram-plpmtud@ietf.org>
Thread-Topic: Path MTU support for Multicast
Thread-Index: AQHWGPz00RnNp2ELqE+FkoqOkBebwA==
Date: Wed, 22 Apr 2020 23:22:55 +0000
Message-ID: <E7647B4B-0690-4ADC-BE41-228F61711A01@akamai.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <C3D783DF77480F42A4A4AB0EF4B3685A@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_08:2020-04-22, 2020-04-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004220177
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_08:2020-04-22, 2020-04-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 spamscore=0 clxscore=1011 phishscore=0 impostorscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220177
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/LAoVh2xQvR57VJq5Qt3jl3bCu0s>
Subject: [pim] Path MTU support for Multicast
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 23:23:11 -0000

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:

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:

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 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

I hope that's helpful.

Best regards,