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

Joe Touch <touch@strayalpha.com> Sat, 07 September 2019 03:47 UTC

Return-Path: <touch@strayalpha.com>
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 F3C0812004E; Fri, 6 Sep 2019 20:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 FPVDd8RdIx8s; Fri, 6 Sep 2019 20:47:22 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 710F6120DE4; Fri, 6 Sep 2019 20:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=HJLuZG0FfAm9yTUZXdwAKjH5FNPAR4HGEm7gQBtlJjU=; b=OkMMg5Q4jdSLgwvC9E1e4fh6R 8HRSHaB/iw1J9UiEixsnwrAxeptWeG3hxMF7Lvr7Ln2Q3ylPQ5fOFrGh97IP/0FCqj0JI++cP1j5m nA2K3xbohRcjdq8IVCLLqEieWHXihdYxjW4a/ciQpzABysyx66kbauV7nCzEOlv+D19qVqQPSs8Gc g8x2+D84S3XZ49eUgJQw9t0nbIKDXcimJkF2ZSl6W+CfujAdwelqVuSNlTlDRhJyLE7iCO40lnJLj 0W/5xs818kaWkuxnc7Uz9dsxg6oaz9SrzfT4A7Kwed90k8F0DEl5dhCmjR+O4/bMpCe2xxVNRsmpf cFgel9ARA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53502 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1i6Rgv-00212Q-HF; Fri, 06 Sep 2019 23:47:17 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org>
Date: Fri, 6 Sep 2019 20:47:12 -0700
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: <8E448D85-8434-4132-BCA8-20123576E8FC@strayalpha.com>
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>
To: Ole Troan <otroan@employees.org>
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/sQm5RCQUyorrKOUeCwMwz53scIQ>
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 03:47:24 -0000


> On Sep 6, 2019, at 9:03 AM, Ole Troan <otroan@employees.org> wrote:
> 
> Joe,
> 
> edited to focus on the two added "recommendation sentences".
> 
>>>>> 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.

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

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

Frag and reassembly outside of an app can be, in some cases, more efficient - even with additional layers of headers.

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

Joe