Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Thu, 09 April 2020 17:14 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083CF3A0D73; Thu, 9 Apr 2020 10:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 SEKCzO-Regt8; Thu, 9 Apr 2020 10:14:01 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2CD3A0D3B; Thu, 9 Apr 2020 10:14:00 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 039HDttS008400; Thu, 9 Apr 2020 10:13:55 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 039HDsxg008399; Thu, 9 Apr 2020 10:13:54 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202004091713.039HDsxg008399@gndrsh.dnsmgr.net>
In-Reply-To: <MN2PR19MB4045F4E4A42E265060ACDF5D83C10@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
Date: Thu, 9 Apr 2020 10:13:54 -0700 (PDT)
CC: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-tsvwg-datagram-plpmtud@ietf.org" <draft-ietf-tsvwg-datagram-plpmtud@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/KcA6Qg1xf-Mw2jqOJkAcQp31SwI>
Subject: Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 17:14:03 -0000

> Hi Robert,
> 
> Commenting as an individual on this idea:
> 
> > Not the subject of this document, but it feels like life could be significantly
> > simpler if somehow there was a mechanism to getting a set of agree a set of
> > defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
> > 4000, 8000, 16000 octets.   My assumption here is that the underlying core link
> > MTUs would be higher to cope with header overheads.
> 
> That would indeed be nice, but the plethora of tunnels and encapsulations in use suggests that boundary effects could result in the packet size settling to an MTU considerably smaller than possible.  For example, suppose that the underlying link is sized to support a 4000 byte MTU with some set of headers to which a tunnel that the link designers didn?t consider adds 64 bytes - having the MTU drop to 2000 bytes would not be a good result.

I would like to point out that this *is* done in implementations to
hunt for an MTU.  From FreeBSD sys/netinet/ip_icmp.c:
/*
 * Return the next larger or smaller MTU plateau (table from RFC 1191)
 * given current value MTU.  If DIR is less than zero, a larger plateau
 * is returned; otherwise, a smaller value is returned.
 */
int
ip_next_mtu(int mtu, int dir)
{
        static int mtutab[] = {
                65535, 32000, 17914, 8166, 4352, 2002, 1492, 1280, 1006, 508,
                296, 68, 0
        };

IIRC the current Path MTU code in FreeBSD would infact land on a
2002 byte MTU for a TCP connection going through the tunnel that David
describes above by the nature of how it works.

> 
> Thanks, --David (as an individual)
> 
> > -----Original Message-----
> > From: Robert Wilton via Datatracker <noreply@ietf.org>
> > Sent: Thursday, April 9, 2020 7:31 AM
> > To: The IESG
> > Cc: draft-ietf-tsvwg-datagram-plpmtud@ietf.org; tsvwg-chairs@ietf.org;
> > tsvwg@ietf.org; Wesley Eddy; wes@mti-systems.com
> > Subject: Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-
> > 19: (with COMMENT)
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-tsvwg-datagram-plpmtud-19: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Firstly I would like to say thank you for writing this document.
> > 
> > I have a general concern, not specifically with this document, but with the
> > overall complexity of the solution.  I.e. the algorithm that is described has
> > to contend with a lot of unreliable information (e.g. are packets dropped
> > because of congestion or some other routing failure, hard to know whether PTB
> > messages can be relied upon etc), there are also several different ways that
> > the probes can be sent etc.
> > 
> > Not the subject of this document, but it feels like life could be significantly
> > simpler if somehow there was a mechanism to getting a set of agree a set of
> > defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
> > 4000, 8000, 16000 octets.   My assumption here is that the underlying core link
> > MTUs would be higher to cope with header overheads.
> > 
> > A few comments on specific sections of the document:
> > 
> > 1) I would include PTB in the terminology section.
> > 
> > 3. Features Required to Provide Datagram PLPMTUD
> > 
> > Most of the the requirements in this section use RFC 2119 language, but a few
> > don't:
> > 
> >    7.   Probing and congestion control: The decision about when to send
> >         a probe packet does not need to be limited by the congestion
> >         controller.  When not controlled by the congestion controller,
> >         the interval between probe packets MUST be at least one RTT.  If
> >         transmission of probe packets is limited by the congestion
> >         controller, this could result in transmission of probe packets
> >         being delayed or suspended during congestion.
> > 
> > Rather than "does not need to be limited", would this be better stated as
> > "SHOULD NOT be limited" or "MAY not be limited"?
> > 
> >    11.  Probing and flow control: Flow control at the PL concerns the
> >         end-to-end flow of data using the PL service.  This does not
> >         apply to DPLPMTU when probe packets use a design that does not
> >         carry user data to the remote application.
> > 
> > The second sentence could be stated something like:
> > 
> > "Flow control MUST NOT apply to DPLPMTU when probe packets use a design
> > that
> > does not carry user data to the remote application"
> > 
> > 5.1.2.  Constants
> > 
> >    MIN_PLPMTU:  The MIN_PLPMTU is the smallest allowed probe packet
> >       size.  For IPv6, this value is 1280 bytes, as specified in
> >       [RFC8200].  For IPv4, the minimum value is 68 bytes.
> > 
> > Does it really make sense to probe for a path MTU of 68 bytes.  Would it make
> > sense for applications to be able to control the MIN_PLPMTU that they find
> > acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280, perhaps
> > many
> > applications/implementations would like to use 1280 as a reasonable lower
> > bound
> > rather than 68 bytes?
> > 
> > 
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org