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

Ole Troan <otroan@employees.org> Sat, 07 September 2019 09:09 UTC

Return-Path: <otroan@employees.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B23120E8E; Sat, 7 Sep 2019 02:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzlSJNovmDjt; Sat, 7 Sep 2019 02:09:15 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B6512007C; Sat, 7 Sep 2019 02:09:15 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:c078:d4b9:b03d:5acc:1b47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C675C4E11AF5; Sat, 7 Sep 2019 09:09:13 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id CB78C1BC11EE; Sat, 7 Sep 2019 11:09:10 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <8E448D85-8434-4132-BCA8-20123576E8FC@strayalpha.com>
Date: Sat, 07 Sep 2019 11:09:10 +0200
Cc: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD8E402E-9B98-461D-8425-62B6F023E78D@employees.org>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org> <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com> <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org> <8E448D85-8434-4132-BCA8-20123576E8FC@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/s6ciELNbOV5zFioY2TY6ci_cMKY>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Sep 2019 09:09:18 -0000

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

>>> 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.
2) If the PMTUD between Host A and security gateway is 1280, then the tunnel would have to support link-layer fragmentation anyway, because of the minimum MTU requirement.

There are lots of considerations here.
Which is why I do not think adding the new sentence that Bob suggested is a good idea.

  "The risks of IP fragmentation can also be mitigated
  through the use of encapsulation, e.g., by transmitting IP fragments
  as payloads."

>> ...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.
Secondly, the goal of this document is not to "rescue IP fragmentation" at any cost.
In your above scheme it is arguable if it is even network layer fragmentation.
Tunnels as link-layers can define their own link-layer specific fragmentation mechanism. That is a lot more efficient than carrying a superfluous extra header with you.
But I don't think any of this can be in the scope of the document.

> 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.
The large scale deployments of this kind of thing is for example TSO/GSO. 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).

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

Section 6.1 with the two sentences deleted:



6.1.  For Application and Protocol Developers

 Developers SHOULD NOT develop new protocols or applications that rely
 on IP fragmentation.  When a new protocol or application is deployed
 in an environment that does not fully support IP fragmentation, it
 SHOULD operate correctly, either in its default configuration or in a
 specified alternative configuration.

 While there may be controlled environments where IP fragmentation
 works reliably, this is a deployment issue and can not be known to
 someone developing a new protocol or application.  It is not
 recommended that new protocols or applications be developed that rely
 on IP fragmentation.  Protocols and applications that rely on IP
 fragmentation will work less reliably on the Internet.

 Legacy protocols that depend upon IP fragmentation SHOULD be updated
 to break that dependency.  However, in some cases, there may be no
 viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
 in-IP encapsulation).  Applications and protocols cannot necessarily
 know or control whether they use lower layers or network paths that
 rely on such fragmentation.  In these cases, the protocol will
 continue to rely on IP fragmentation but should only be used in
 environments where IP fragmentation is known to be supported.

 Protocols may be able to avoid IP fragmentation by using a
 sufficiently small MTU (e.g.  The protocol minimum link MTU),
 disabling IP fragmentation, and ensuring that the transport protocol
 in use adapts its segment size to the MTU.  Other protocols may
 deploy a sufficiently reliable PMTU discovery mechanism
 (e.g.,PLMPTUD).

 UDP applications SHOULD abide by the recommendations stated in
 Section 3.2 of [RFC8085].




Cheers,
Ole