Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

Joe Touch <touch@strayalpha.com> Fri, 15 November 2019 14:50 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 7E06C12087A for <int-area@ietfa.amsl.com>; Fri, 15 Nov 2019 06:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 4nqJmi8ZGhs4 for <int-area@ietfa.amsl.com>; Fri, 15 Nov 2019 06:50:18 -0800 (PST)
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 DCA66120810 for <int-area@ietf.org>; Fri, 15 Nov 2019 06:50:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=mTdviDQactrL2A9lel/8fB2Pder4ZuiOasehbCX2/y0=; b=QBqLqSDzZku9eyTVQV2AeVXWP D4lUHMkHpBG46HUkg9Kh6Wl0BxsA5DTddVLln3DLGZzHgziILqBVGxEF/FK0HQoRrcrID5/xNt36M SGmSWBE+BxDHeUHttCyagXeuCdxbgaHPluwmxTSB8B+OYM7ELa3wQo7jYpTsXQ1/9wFYrw6TtAj2a F/Zy1Fdz6F8Hu9QbO9jH2II8PuuZri+c1wjPI4FiRY4izt3XDATxMHQu3Dj6HGKCfTKEb5LYUuEST BQY6Yz8Harx87Yyrkh5N0PlOpIQUdKh4VDPpmc7rrTRYFDBnFiwDIAHnws87hZTajwn+p65b8KzmP lChi3e1jg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64450 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 1iVcvL-002GsU-BW; Fri, 15 Nov 2019 09:50:16 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_618B6ACF-3BC2-47EE-80CE-6FE939C6510D"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <81496B9A-2325-47FB-994D-C287CEFFE4D9@juniper.net>
Date: Fri, 15 Nov 2019 06:50:10 -0800
Cc: "int-area@ietf.org" <int-area@ietf.org>
Message-Id: <C8B1D481-F7E8-4E49-903D-D9FD46001759@strayalpha.com>
References: <81496B9A-2325-47FB-994D-C287CEFFE4D9@juniper.net>
To: Manoj Nayak <manojnayak@juniper.net>
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/-xH0wLJiT9CYVBfVfr1lKNGx3EU>
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt
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: Fri, 15 Nov 2019 14:50:21 -0000


> On Nov 13, 2019, at 8:34 PM, Manoj Nayak <manojnayak@juniper.net> wrote:
> 
> Hello Joe,
> 
> Please find my reply.
> 
>>> - why does this doc assume the max ICMP is 576?
>>>      we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits of the orig payload are guaranteed)
>>>      (yes, your note in the end of sec 1 is relevant, but given v4-in-v4 tunneling, it?s possible that 
>>> paths might be smaller than the 576 assumption)
> 
> We use an unused field in first 8 bytes of ICMP error/reply message.

Please explain. Most ICMP messages have 4 bytes of unused field, but not all (one has only 3).

> How the idea would be
> affected if minimum packet size is 68 bytes or 576 bytes. As per my understanding,
> existing ICMP error/reply message works in v4-in-v4 tunnelling, so it would continue to 
> work with the idea proposed in our draft. we won’t let the ICMP message exceed a reasonable size. 
> in our implementation, that will be 576.

Sending the largest response possible given an untunneled MTU size is an invitation to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel is encountered.

In most situations, ICMP responses are received from small initial messages that don’t stress that limit. The use in this doc is the opposite - it relies on ongoing use of ICMP for max-sized packets and returns max-sized payloads. This isn’t helpful. It would be more useful to try to limit the size to the minimum expected to be useful and account for these other encapsulations.

> 
>>> - why would this approach find the largest fragment through a system?
>>>      rfc1812 talks about various strategies, one of which is ?equal sized?, which might never find 
>>> the max the way you propose
> 
> 
> As per section 4.2.2.7 from rfc 1812,
> 
> “There are several fragmentation techniques in common use in the
> Internet.  One involves splitting the IP datagram into IP
> fragments with the first being MTU sized, and the others being
> approximately the same size, smaller than the MTU. “
> 
> In both of the above cases, idea in our draft works.

The issue is further down in that section:

      One other fragmentation technique discussed was splitting the IP
      datagram into approximately equal sized IP fragments, with the
      size less than or equal to the next hop network's MTU. ...

In that case, none of the fragments gives you the path MTU.

Joe