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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 06 June 2016 20:38 UTC

Return-Path: <Fred.L.Templin@boeing.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 2D1C812D90F; Mon, 6 Jun 2016 13:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8cCpSW4nSNCq; Mon, 6 Jun 2016 13:38:14 -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 DEF9C12D919; Mon, 6 Jun 2016 13:38:03 -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 u56Kc32B042972; Mon, 6 Jun 2016 13:38:03 -0700
Received: from XCH15-05-07.nw.nos.boeing.com (xch15-05-07.nw.nos.boeing.com [137.136.239.209]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u56KbxHG042832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 6 Jun 2016 13:38:00 -0700
Received: from XCH15-05-11.nw.nos.boeing.com (2002:8988:efd5::8988:efd5) by XCH15-05-07.nw.nos.boeing.com (2002:8988:efd1::8988:efd1) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Jun 2016 13:37:58 -0700
Received: from XCH15-05-11.nw.nos.boeing.com ([137.136.239.213]) by XCH15-05-11.nw.nos.boeing.com ([137.136.239.213]) with mapi id 15.00.1178.000; Mon, 6 Jun 2016 13:37:59 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@herbertland.com>, Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.
Thread-Index: AQHRvbdPveimCbx8+kiS+Bdydthih5/c6X4w
Date: Mon, 6 Jun 2016 20:37:58 +0000
Message-ID: <3d29bcbfc1f04033aee4285e4dae31f4@XCH15-05-11.nw.nos.boeing.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> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D55B37B@NKGEML515-MBS.china.huawei.com> <CALx6S34fodntzDOagKOsfey9hfAZpsAS_xg6Rjw767B=gacvVQ@mail.gmail.com>
In-Reply-To: <CALx6S34fodntzDOagKOsfey9hfAZpsAS_xg6Rjw767B=gacvVQ@mail.gmail.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-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/9TEepAk9vVL-az9QNNaPbIBAjFg>
Cc: "int-area@ietf.org" <int-area@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, Joe Touch <touch@isi.edu>, "nvo3@ietf.org" <nvo3@ietf.org>, Softwires WG <softwires@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [Softwires] [tsvwg] [Int-area] [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: Mon, 06 Jun 2016 20:38:17 -0000

Hi Tom,

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tom Herbert
> Sent: Friday, June 03, 2016 9:45 AM
> To: Xuxiaohu <xuxiaohu@huawei.com>
> Cc: int-area@ietf.org; lisp@ietf.org; Joe Touch <touch@isi.edu>du>; nvo3@ietf.org; otroan@employees.org; Softwires WG
> <softwires@ietf.org>rg>; tsvwg@ietf.org
> Subject: Re: [tsvwg] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.
> 
> On Fri, Jun 3, 2016 at 12:38 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> >
> >
> >> -----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)?
> >
> That is precisely solution #3 in RFC4459:
> 
> "Ensure that in the specific environment, the encapsulated packets
> will fit in all the paths in the network, e.g., by using MTU bigger
> than 1500 in the backbone used for encapsulation."
> 
> If you're able to implement this in you network that's great, but it
> is not feasible in all situations and hence can't be the standard. We

I agree. So then, what *should* be the standard is GUE plus fragmentation
plus direct IP encapsulation. I think that should cover all use cases, right?

Thanks - Fred

> may not control all the underlay networks (definitely not over the
> Internet) and hence not be able to set all the MTUs large enough. Also
> an MTU greater than 1500 require jumbo frames, not all networks
> enabled those.
> 
> One other point, when a device sources or sinks IP packets like in
> tunneling it is taking on the role of a host and so we expect host
> requirements apply. For instance, routers may perform fragmentation in
> IPv4, but they do not perform fragmentation for IPv6 or reassembly
> (those are hosts functionalities). There has been at least one attempt
> to carve out exceptions in applying host requirements to devices that
> perform tunneling, that is an allowance to send a zero UDP checksum in
> in IPv6. Documenting this took two RFCs and we still needed a whole
> lot of description in at least GRE/UDP on requirements that to use the
> non-zero checksum. I don't think standardizing exceptions in
> fragmentation for tunnels would be any easier.
> 
> Tom
> 
> > 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
> >
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
>