IETF Logo Mail Archive

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 24 July 2018 22:54 UTC

Return-Path: <Fred.L.Templin@boeing.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 0B6EE131218; Tue, 24 Jul 2018 15:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 WJ_Erq2wMMKX; Tue, 24 Jul 2018 15:54:13 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 D42A1131217; Tue, 24 Jul 2018 15:54:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w6OMs9EF026128; Tue, 24 Jul 2018 15:54:09 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w6OMs5ah026098 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 24 Jul 2018 15:54:05 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 24 Jul 2018 15:54:04 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Tue, 24 Jul 2018 15:54:04 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Wassim Haddad <wassim.haddad@ericsson.com>, "internet-area@ietf.org" <int-area@ietf.org>
CC: "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Thread-Topic: WG Adoption Call: IP Fragmentation Considered Fragile
Thread-Index: AQHUI4aGFkqwG7lztkapJHj3/IpHTqSe33AQ
Date: Tue, 24 Jul 2018 22:54:04 +0000
Message-ID: <e794c5ddbb814c0384c8dd06eb6acf7c@XCH15-06-08.nw.nos.boeing.com>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com>
In-Reply-To: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/KQqAJuXk-3qRWkbrKNPoSD5Cb18>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 22:54:16 -0000

I have an observation that I would like to see addressed in the document. Some applications
(e.g., 'iperf3' and others) actually leverage IP fragmentation to achieve higher data rates than
are possible using smaller (but unfragmented) whole packets.

Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets to fragment across
paths that support only smaller MTUs. I have seen iperf3 exercise IP reassembly at line rates
on high-speed links, i.e., it shows that reassembly at high rates is feasible.

We know from RFC4963 that there are dangers for reassembly at high rates, but there are
applications such as iperf3 that ignore the "SHOULD NOT" and leverage IP fragmentation
anyway. So, should the "SHOULD NOT" have an asterisk?

Thanks - Fred

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Wassim Haddad
> Sent: Tuesday, July 24, 2018 12:43 PM
> To: internet-area@ietf.org <int-area@ietf.org>
> Cc: intarea-chairs@ietf.org
> Subject: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
> 
> Dear all,
> 
> We would like to start a WG adoption call for draft-bonica-intarea-frag-fragile (“IP Fragmentation Considered Fragile”).
> 
> https://www.ietf.org/id/draft-bonica-intarea-frag-fragile-03.txt
> 
> 
> Please indicate your preferences on the mailling list. The deadline is August 10th.
> 
> 
> Thanks,
> 
> Juan & Wassim
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

v2.23.0 | Report a Bug | By Email