Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Joe Touch <> Sat, 07 September 2019 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA9CC120B48; Sat, 7 Sep 2019 08:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 96-ePhI0gm2t; Sat, 7 Sep 2019 08:16: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 300AA120B47; Sat, 7 Sep 2019 08:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rtGxBR2oBFl3zT32Gd4CTSfbs5bna8LE9LT059+Sb1g=; b=D1AZTVPwJ4KqcAbjN0ZMyV8vE hiKv+sxxWp2rCR5v6Ja6rSCVhkyfajmbnYJN29aM7Dn/wxCNcreC9rnHp+qqQSEhQiu1lPKo8o6wF L6TOiPHoK+wTjfOk12h+O1Pcen2A/5SgCIP7AS4brcqjuPkIS50bpSzsWXKOvFoxQ2dzlCHo3aaRi EmocdKqwE5bdY/UWYVilAFiFiq1puvwmefkpWyrFlFRamUsMy2MNnQHyhlsgd5U+IObOUIPGgwSFa Y0adfvU+Y2Qm5OcQHVa9+AXY3AMdA8MCWlmXCC0aaEEi5yzEbXWjbfJO2RUIqF/T5nfJsm0UiNTtx /dOvxe4dw==;
Received: from ([]:56711 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1i6cRi-002v1h-5p; Sat, 07 Sep 2019 11:16:18 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sat, 7 Sep 2019 08:16:13 -0700
Cc: Bob Hinden <>, "" <>, Ron Bonica <>, IESG <>, Joel Halpern <>, "" <>, Suresh Krishnan <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Sep 2019 15:16:24 -0000

> On Sep 7, 2019, at 2:09 AM, Ole Troan <> wrote:
>>>>>>> 1) It introduces something new and undescribed in paragraph 2.
>>>>>>> "unless they also include mechanisms to detect that IP fragmentation isn't working
>>>>>>> reliably."
>>>>>>> That seems like hand-waving to me. Suggest deleting.
>>>>>> Fragmentation success or failure is directly testable. Any feedback mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
>>>>>> This differs from ICMP black-holing in path MTU detection.
>>>>> Can you please point me to where in the PLPMTUD document testing for IP fragmentation is described?
>>>> Any feedback mechanism will detect when fragmentation - or anything else - prevents delivery.
>>> Any pointer to such a mechanism in any IETF protocol?
>>> Would be interesting to get transport/application perspective on this.
>>> But unless there is a reference I would claim this is hand-waving.
>> As I said, PLPMTUD. It doesn’t have to detect if there’s a layer of fragmentation it can’t detect; it figures out for itself that a given MTU doesn’t succeed and sends a smaller MTU.
> Sorry, I still don't understand how PLPMTUD detects if fragmentation works reliably or not.
> The paragraph we are disccusing is:
>  "Protocols and applications that rely on IP
>  fragmentation will work less reliably on the Internet unless they
>  also include mechanisms to detect that IP fragmentation isn't working
>  reliably."
> My view is that unless we can point to a reference or specification for how to do this, then it amounts of hand waving.

It’s a homework assignment in a 1st yr net class.

*Any* two-way protocol gets feedback as to whether it works.

If you send large packets and they work, you’re done.

If not, you have to backoff and fragment at the app layer - which is less efficient, but will still get through.


ANY protocol that can adjust to an MTU based on feedback CAN try larger MTUs than the first hop link reports and see if they work.

> And possibly sending application developers out on a wild goose chase.
> And given that applications would have to work in the cases where fragmentation was found to not work reliably…

They have to do this anyway, but this way they don’t have to be stuck with app-layer fragmentation when the network can to it instead.

>>>> If you fragment and put the result inside GRE or UDP, the impact of the fragment (interfering with flow-based multi path routing, nat traversal, etc) is overcome.
>>> Sure, but that only applies to tunnels that go end to end.
>> It applies to tunnels that traverse wherever fragmentation is both needed and doesn’t work other ways.
>> Speaking of deployed mechanisms, it’s also how IPsec tunnels over UDP already work and are widely deployed.
> It does not work.
> Host A -- ipsec tunnel -- SGW -- Host B
> 1) If host A sends fragments inside of the tunnel to host B, the fragments are equally fragile between the security gateway and host B.

It’s not equally fragile. Fragments inside UDP overcome NATs and ECMP that (incorrectly) refuse to support packets without transport headers.

>>> ...This document should not recommend IP in UDP in IP encapsulation to achieve end to end IP fragmentation for new applications.
>> Why not exactly not?
> Firstly, a fundamental architectural change of how we would recommend application transport to work is not appropriate for this document.

There is no architectural change in using UDP for tunnels. There’s a section in RFC 8085 on this if you want a citation.

> ...
>> Frag and reassembly outside of an app can be, in some cases, more efficient - even with additional layers of headers.
> Yes, in _some_ cases. Try to introduce 1% of packet drop and that number of cases likely drop to 0.

(speaking of hand waving…)

> The large scale deployments of this kind of thing is for example TSO/GSO.

Oh, now we’re off into implementation mechanisms (not standards) that don’t follow existing standards either in many cases.

> As a way to bypass bottlenecks in packet processing in the kernel.
> But there segmentation is done at the transport layer, which will not suffer from the issues of a single packet drop in a 40 fragment chain.
> (64K packet / 1500).

Fragmentation is fragmentation. If you send 64K messages and lose one fragment - at any layer of a protocol - you lose the message. Unless you send those fragments over a reliable channel that retransmits (e.g., TCP) anyway. 

>>> If this paragraph has to be there it would be more accepting to have it in the "Legacy protocols" parapgraph above.
>> It’s unnecessarily limiting to mention it only there.
> The whole purpose of this document is to limit use of network layer fragmentation.


It is to reduce the impact of the FAILURE of network layer fragmentation - which IMO is best done through a *variety* of approaches that app and protocol designers can choose.