Re: [Softwires] [nvo3] Is it feasible to perform fragmentation on UDP encapsulated packets.

Xuxiaohu <xuxiaohu@huawei.com> Fri, 03 June 2016 02:53 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5465912D131; Thu, 2 Jun 2016 19:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 B7Jyu9rhZXhE; Thu, 2 Jun 2016 19:53:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741A9128874; Thu, 2 Jun 2016 19:53:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLH32864; Fri, 03 Jun 2016 02:53:44 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 3 Jun 2016 03:53:43 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 3 Jun 2016 10:53:38 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Joe Touch <touch@isi.edu>, "otroan@employees.org" <otroan@employees.org>
Thread-Topic: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.
Thread-Index: AQHRvPncHcsWng18N0qPKCUQaW4bNp/W96xA
Date: Fri, 3 Jun 2016 02:53:37 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com>
References: <E83B905A-FF6D-4996-B71A-7921DE4B133B@ericsson.com> <BFC09F5C-D6DF-4B6B-AA95-03919B9F09FB@cisco.com> <573E2A0E.1060609@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D54EB60@NKGEML515-MBX.china.huawei.com> <573F453C.5060908@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D554B73@NKGEML515-MBS.china.huawei.com> <5743303C.5040109@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55514C@NKGEML515-MBS.china.huawei.com> <5743DD16.3050506@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D555482@NKGEML515-MBS.china.huawei.com> <57448C14.2060203@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5557DE@NKGEML515-MBS.china.huawei.com> <9c462520-eb8e-fcd0-0a08-228f80fbc779@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5596E0@NKGEML515-MBS.china.huawei.com> <8790AF6F-CCD6-43AC-A50E-957B037643F1@employees.org> <57507611.5010801@isi.edu>
In-Reply-To: <57507611.5010801@isi.edu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5750F138.01B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: b6ae068aa12793195ecad703a67f441c
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/t3VNTVaG2a_6dO_El49F_Oz6qeU>
Cc: Softwires WG <softwires@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [Softwires] [nvo3] Is it feasible to perform fragmentation on UDP encapsulated packets.
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2016 02:53:52 -0000


> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Friday, June 03, 2016 2:08 AM
> To: otroan@employees.org; Xuxiaohu
> Cc: Softwires WG; nvo3@ietf.org; int-area@ietf.org; lisp@ietf.org;
> tsvwg@ietf.org
> Subject: Re: [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP
> encapsulated packets.
> 
> 
> 
> On 5/27/2016 3:50 AM, otroan@employees.org wrote:
> > It is not possible to implement reassembly complying with IETF RFCs.
> 
> a) ATM does this at ridiculously high fragment rates. Granted IP frags can come
> out of order, but the fragments are generally much larger.

As pointed in RFC4459,

     "At the time of reassembly, all the information (i.e., all the
      fragments) is normally not available; when the first fragment
      arrives to be reassembled, a buffer of the maximum possible size
      may have to be allocated because the total length of the
      reassembled datagram is not known at that time. Furthermore, as
      fragments might get lost, or be reordered or delayed, the
      reassembly engine has to wait with the partial packet for some
      time (e.g., 60 seconds [9]).  When this would have to be done at
      the line rate, with, for example 10 Gbit/s speed, the length of
      the buffers that reassembly might require would be prohibitive. "

Have you heard the wide adoption of 622M (STM-1) beyond ATM interfaces between ATM switches in the previous ATM networks? If not, the highest non-ATM interface in the past ATM networks was the FE interface which is 100M bps (around the year of 2000), If I remembered it correctly. Furthermore, have you heard the reordering issue with ATM cells? If no, that means once an ATM cell of a given ALL PDU gets lost, all the received ATM cells of that AAL PDU would be dropped and therefore the reassembly buffer for that AAL datagram would be released. In other words, there is no need to wait for the lost or reordered fragment for a certain period of time before releasing the reassembly buffer. Such behavior is not possible for IP fragmentation and reassembly. Last but not least, there is no need to assign a reassembly buffer per AAL PDU (as opposed to per IP datagram in the IP fragmentation and reassembly case), instead, only one reassembly buffer per VC since all cells within a given VC would be received in order. Since the SAR is only needed on the edge of the ATM networks, the number of VCs is very limited. In a word, there are significant differences between IP fragmentation and ATM SAR. 

Best regards,
Xiaohu

> b) What is the alternative, given we have minimum MTU requirements?
> 
> If you're limiting yourself to IPv4 payloads where DF=0, sure, there there is an
> alternative. But you've just disabled IPv6 and IPv4 with DF=1.
> 
> I.e., it's not possible to NOT implement this and comply with IETF RFCs.
> 
> Joe
> 
>