Re: [pim] Path MTU support for Multicast

"Nandy, Tathagata" <> Thu, 23 April 2020 03:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C2DC3A12C8; Wed, 22 Apr 2020 20:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDLnyvGTiJ6g; Wed, 22 Apr 2020 20:54:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6567A3A12C7; Wed, 22 Apr 2020 20:54:22 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 03N3ho6R028063; Thu, 23 Apr 2020 03:54:16 GMT
Received: from ( []) by with ESMTP id 30jnt35yda-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 03:54:16 +0000
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88EBBB8; Thu, 23 Apr 2020 03:54:15 +0000 (UTC)
Received: from (2002:10d2:1510::10d2:1510) by (2002:10d8:a104::10d8:a104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Apr 2020 03:54:15 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 23 Apr 2020 03:54:14 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=VcwDzeYpAZ+tATMyX+QJ3BFu55R7sM+4LluJxKzr7ykgUTLaT9+qN1vzAXlSM9meZXoJHqY7ULqf2h845yepKGhYQjRGlBYRTs0ZeHJH2Xb38QuzibyLTKou3X60eMHHciP4T9OExT+8vMUFRdm+daKqWYZo0VBU6V9ZWpD78H8ma9/2YcwKJG2J0ckMWzd3bBeET6Q7g6HAog3K3Uu63JbRwe8Joecs6ERzeJnPybqG24Ji1Z/6AUuaB8CaZEIM7N7/31Vt8kgrWf+h0U2EH39zqyrsIzur3OCuga3fnXGzKW4j+eNJaYmtPoiKOvrTwhk1e6B4vDnHe98Lt1JWlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xlk1siHB/bRObV8hVX7+4qOZEPRStIpd9zbxN7Yzdug=; b=eImhexorimvS4hjZBCY3clZr4E6TIY/t6IQzJnueILd04vFNAULjxW8rsQN+J6RQj1lg5sTSEVT+H83UlrJEr+So2piVDDITUz/IOqVOM2P/slC6cVXQ/bQI7sNyL8B34w0YS7A9WRt3FWJOABEg6EoNdxK1Ey20JemsX1ML5s7D09iBzgBkhkc35kqs6vHcymziN2YmXEf+7VgLbjQqtdZQgOpF+/D5EfWKYQ/zLsRGWd+yfdwCUIS/xWy0sDnnqlpkPRZL5mpDYXc+qtPLYZg+Lk1suzuRCaOKQgZ+N3L1CU9jVZMkbN//mKbHvwh5I3S6FJlTGkGRP0Y3tmYrKw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
Received: from DF4PR8401MB0858.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:760a::20) by DF4PR8401MB0793.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7606::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Thu, 23 Apr 2020 03:54:14 +0000
Received: from DF4PR8401MB0858.NAMPRD84.PROD.OUTLOOK.COM ([fe80::ac64:d7b4:5151:ffb7]) by DF4PR8401MB0858.NAMPRD84.PROD.OUTLOOK.COM ([fe80::ac64:d7b4:5151:ffb7%11]) with mapi id 15.20.2921.032; Thu, 23 Apr 2020 03:54:14 +0000
From: "Nandy, Tathagata" <>
To: "Holland, Jake" <>, "" <>
CC: MBONED WG <>, "" <>, "" <>
Thread-Topic: Path MTU support for Multicast
Thread-Index: AQHWGPz00RnNp2ELqE+FkoqOkBebwKiGEx9g
Date: Thu, 23 Apr 2020 03:54:14 +0000
Message-ID: <DF4PR8401MB0858EF7712A28596DDAB914DE1D30@DF4PR8401MB0858.NAMPRD84.PROD.OUTLOOK.COM>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 70135424-a46d-46cc-7156-08d7e739fd1a
x-ms-traffictypediagnostic: DF4PR8401MB0793:
x-microsoft-antispam-prvs: <DF4PR8401MB0793BB1230263B16F299E04BE1D30@DF4PR8401MB0793.NAMPRD84.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:1247;
x-forefront-prvs: 03827AF76E
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DF4PR8401MB0858.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(39860400002)(366004)(376002)(136003)(396003)(346002)(9686003)(26005)(2906002)(66476007)(66556008)(64756008)(66946007)(76116006)(66446008)(55016002)(52536014)(186003)(478600001)(86362001)(54906003)(33656002)(110136005)(71200400001)(55236004)(81156014)(7696005)(5660300002)(53546011)(8936002)(966005)(4326008)(8676002)(316002)(6506007); DIR:OUT; SFP:1102;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NzHk+Fc1MMuO1hDwnIJ7epp9ITQA9Kft27is/sU9GECmwDZmHtw1FImcOEw/EK/i4TI4ZK+32nkzk1pcW6uQBN6dU0pRih3G9ubOIX988bC8ifttBhK9Hq7PY+8ZHgpDvu/4ez6RK7NTTlP9D0vC0DPlyW5lGhp66NOjzvdQ4nzlNNbu11uRvK8m2ePGZeM6GZc8tYkbG1g7qhdtZdxo0G/Adzciyph7eG+mm/Naq5U31zLqNnLxJB2e8j6LyiDYKJuLKclS9fUGpu5ide3dJmZNl989J55Knk19IgfDSJXCAszd6DQ5zv+OrdOxBkGkSZ8Ni6mRnx+f6Tg+WPoTkzMh78suMmuDOWndY0glxPDdUZJ47jcGg+wXUDVaQWkqSp/mOt0gr40BBRoShgbZvAG3TfDjac8FLlOCL1zbWnw7F2hyMA6SPMylleinE2LbvTg48u0xgQMXsr5XjVYD3FPhDRnF8X04sNDgv0r5GylsaMds/qFkaUs+pAkm7hsegV7Fkf2UX8/mNfB0aKDElg==
x-ms-exchange-antispam-messagedata: AzFNsZolKdcq3AKyNSoB2e80v2iQ37gGfFX0EiLZgOeGJnpCKr9sa1WgXPiYK0NQRgRvBb1PjtHBCgz0m1RQJhwURvAz35UaZd/JYcLp3E9E11XSt+V5sS8hQNW1ryCM2LSoRW0z66J22ji9ktMiFA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
X-MS-Exchange-CrossTenant-Network-Message-Id: 70135424-a46d-46cc-7156-08d7e739fd1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 03:54:14.0795 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WKH5VNkRSA8PJNb+0lHclGDPOLmNuIIkm1nhw4fwKYmF88ony9ja+ljRLtS/+xroygBUiE6xO/SibMIw+Sz2Fg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0793
Content-Transfer-Encoding: base64
X-Proofpoint-UnRewURL: 2 URL's were un-rewritten
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=outbound_notspam policy=outbound score=0 impostorscore=0 suspectscore=0 phishscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 adultscore=0 bulkscore=0 clxscore=1011 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004230023
Archived-At: <>
Subject: Re: [pim] Path MTU support for Multicast
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Apr 2020 03:54:25 -0000

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. 


-----Original Message-----
From: Holland, Jake [] 
Sent: Thursday, April 23, 2020 4:53 AM
To:; Nandy, Tathagata <>
Cc: MBONED WG <>rg>;;
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: 

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 doesn't).

I hope that's helpful.

Best regards,