RE: End System PMTUD behavior question

<Peter.Hunt@nokia.com> Thu, 22 January 2009 23:55 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipngwg-archive@lists.ietf.org
Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0070D3A6806; Thu, 22 Jan 2009 15:55:35 -0800 (PST)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D633D3A6806; Thu, 22 Jan 2009 15:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JGxB-8QThAZ; Thu, 22 Jan 2009 15:55:32 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 857E73A677C; Thu, 22 Jan 2009 15:55:32 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0MNsgw2022833; Fri, 23 Jan 2009 01:54:44 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 01:54:44 +0200
Received: from vaebe108.NOE.Nokia.com ([10.160.244.69]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 01:54:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: End System PMTUD behavior question
Date: Fri, 23 Jan 2009 01:54:39 +0200
Message-ID: <808F2ECE7425024994976AC3D44BDCF4C8B900@vaebe108.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: End System PMTUD behavior question
thread-index: Acl7+fSDtCRQmHdATNy7UebOW+92QAACmYbgAASrC5AAK66ZwAAI127Y
References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA@IMCMBX1.MITRE.ORG><B00EDD615E3C5344B0FFCBA910CF7E1D0632C176@xmb-rtp-20e.amer.cisco.com><3C6F21684E7C954193E6C7C4573B762701D3DD69E6@IMCMBX1.MITRE.ORG> <B00EDD615E3C5344B0FFCBA910CF7E1D0632C194@xmb-rtp-20e.amer.cisco.com>
From: <Peter.Hunt@nokia.com>
To: <shemant@cisco.com>, <jdunn@mitre.org>
X-OriginalArrivalTime: 22 Jan 2009 23:54:40.0026 (UTC) FILETIME=[CA0597A0:01C97CEC]
X-Nokia-AV: Clean
Cc: fhuang@mitre.org, ksherman@mitre.org, ipv6@ietf.org, csliou@mitre.org, steve_eiserman@uscourts.gov, ipv6-bounces@ietf.org, v6ops@ops.ietf.org, pgrayeli@mitre.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0174434914=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format.

Hemant,
 
Forgive me if I've misunderstood, but it sounds like you're saying that we should require protocols or applications above IP to always send data in messages small enough to avoid IP fragemntation.
 
I agree it makes sense for a higher layer to use the PMTU information in IP's cache when it can. Expecting TCP to use the PMTU is perfectly reasonable, as it's already chopping up a byte stream into packets. For protocols which are already packetized, though, I think it's less advantageous to burden them (or the application using them) with the problem of fragmentation and reassembly, to avoid IP fragmentation.
 
For example, if a user does a "ping -s 1500" to a destination whose PMTU is 1280, the only way to avoid IP fragmentation is for the ping application to split the data into multiple messages, or for IPCMPv6 to do so. Either way, you have to introduce some way to identify them as "ping fragments" and reassemble them in order. That will require changes to the ICMPv6 protocol, I think. Furthermore, you're no longer really doing a "ping 1500", but two pings of 1280 and 220 bytes, respectively.
 
In the case of an application which sends records in single UDP frames, to avoid fragmentation is must split its messages into MTU-sized chuncks, and come up with a way at the destination to identify and reassemble the chunks in order. This seems a bit unreasonable, given that IPv6 has a perfectly good mechanism to do this already.
 
So I think the behaviour observed by Thomas during his testing is correct. I don't think ping or ICMPv6 should reduce the ICMP message size to avoid IP fragmentation.
 
Peter Hunt
Software Engineer
Nokia S&S.
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------