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

Xuxiaohu <xuxiaohu@huawei.com> Fri, 03 June 2016 07:38 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 1BB7512D670; Fri, 3 Jun 2016 00:38:51 -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 R3Qiwwov-_9K; Fri, 3 Jun 2016 00:38: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 16A9012D0DE; Fri, 3 Jun 2016 00:38:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLH62853; Fri, 03 Jun 2016 07:38:43 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 3 Jun 2016 08:38:42 +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 15:38:40 +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//+qsICAAKCTIA==
Date: Fri, 3 Jun 2016 07:38:40 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@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> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B2A4@NKGEML515-MBS.china.huawei.com> <575108D3.3010506@isi.edu>
In-Reply-To: <575108D3.3010506@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.0A090202.57513404.004D, 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/8fmXbvE7_UKo7VDFZIc1fAbCFc8>
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 07:38:51 -0000


> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Friday, June 03, 2016 12:34 PM
> To: Xuxiaohu; otroan@employees.org
> 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 6/2/2016 7:53 PM, Xuxiaohu wrote:
> >
> >> -----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. "
> 
> Yes, but the alternative of declaring that you don't reassemble has a cost in
> terms of dropped segments too.

The alternative is to configure the MTU of the core large enough to accommodate the added encapsulation header. This is a feasible and proven approach in well-managed SP networks. No packet loss and no forwarding performance degradation.

> Taking that drop into account, buffering for a smaller amount of potential
> reordering and accounting for reasonable reassembly sizes (for IPv6, the
> smallest "max" that's required is 1500) need not be prohibitive.

In the IPv6-in-IPv4 Software network case, assume the MTU of the core is not large enough than 1280+20, all the IPv6 traffic across the tunnels would have to be fragmented and then reassembled. Not a small amount.

> > 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.
> 
> OC12 ATM NICs were commonly available in 1998. That was back when

Sorry, there was a spelling mistake ( s/STM-1/STM-4).

OC12/STM-4=622M. My question is have you heard the wide adoption of 622M (STM-4) BEYOND ATM interfaces (e.g., STM-16/OC48) at that time?

> ethernet was pushing 100M and the only other near-gigabit tech was Myricom
> (a spin-off of USC/ISI and Caltech). I.e., with the tech available at that time,
> 600Mbps SAR was possible.

Was that 600Mbps SAR capability proved in real networks? And for what service?

> > 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.
> Reordered no, but just because they arrive in order does not mean they are
> required to arrive *adjacent*. The same requirement applies in terms of
> needing reassembly buffers for a number of interleaved segments.

However, the reassembly buffer requirement is limited due to the fact that only one buffer is needed per VC and the total number of VCs is not large on the edge of ATM networks. In contrast, the number of IP flows is uncontrollable.

> >  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.
> You could easily decide to allocate a fixed number of reassembly buffers per IP
> flow to conserve resources too. The amount of reordering, together with the

What about in the DDoS attack case? Do you believe that SPs would allow the existence of that obvious DDoS attack risk in their networks and afford the significant forwarding performance degradation? especially when there has been a feasible and proven solution to the MTU issue (i.e., configure the MTU of the core large enough)?

Best regards,
Xiaohu

> number of flows supported would determine your ability to avoid packet drops
> -- but recall that drops at high load are not unusual for IP.
> 
> Joe