motivation for draft-ietf-6man-mtu-option-02

Tianran Zhou <zhoutianran@huawei.com> Tue, 17 March 2020 09:42 UTC

From: Tianran Zhou <zhoutianran@huawei.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: motivation for draft-ietf-6man-mtu-option-02
Thread-Topic: motivation for draft-ietf-6man-mtu-option-02
Thread-Index: AdX8PJw3KPd8IMUBQMKaI31SWFfh0g==
Date: Tue, 17 Mar 2020 09:42:13 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BF2BAD88@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF2BAD88NKGEML515MBXchi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Wfcq8DXna-hvXBLwHHwRgSQjzXc>
Precedence: list

Hi Bob and Gorry,

I am looking at all the PMTU detection drafts in IETF. There are many solutions varying from IP layer, transport layer, ICMP, etc.
With already so many ways to detect PMTU, why we need this?
In "2.  Motivation and Problem Solved" , I see your main reason is:
"Nodes in the middle of the network may not send ICMP Packet Too Big messages or they are rate limited to the point of not making them a useful mechanism."
What's the matter? And what if we use DPLPMTUD which do not rely on ICMP?
On the proposal in this draft, using HbH option.
1. HbH option may be dropped in real network, so not able to complete the detection.
2. If a node ignore the HbH option, the detection result may not be correct, and so cannot guide the right transport layer fragmentation.

Look forward to seeing your thoughts.

Thanks,
Tianran

motivation for draft-ietf-6man-mtu-option-02 Tianran Zhou