Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Joe Touch <touch@isi.edu> Tue, 28 January 2014 16:41 UTC

Return-Path: <touch@isi.edu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D19A1A02EA; Tue, 28 Jan 2014 08:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
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 GWO1aLhAmlxH; Tue, 28 Jan 2014 08:41:55 -0800 (PST)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A61A02D5; Tue, 28 Jan 2014 08:41:55 -0800 (PST)
Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0SGecLE029899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jan 2014 08:40:41 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset="iso-8859-1"
From: Joe Touch <touch@isi.edu>
In-Reply-To: <CACKN6JF9DMNTftj8TwrYDW1ASFQbO2ronX2LDj6eYDa4bjTLdA@mail.gmail.com>
Date: Tue, 28 Jan 2014 08:40:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB36D802-970E-4C49-A006-B90DD522D9FD@isi.edu>
References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu> <52E6B128.8060306@joelhalpern.com> <52E6B272.4030703@isi.edu> <CACKN6JF9DMNTftj8TwrYDW1ASFQbO2ronX2LDj6eYDa4bjTLdA@mail.gmail.com>
To: Edward Crabbe <edc@google.com>
X-Mailer: Apple Mail (2.1827)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: joel jaeggli <joelja@bogus.com>, "mpls@ietf.org" <mpls@ietf.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 16:41:57 -0000

On Jan 27, 2014, at 4:25 PM, Edward Crabbe <edc@google.com> wrote:

> I assume we're talking about the chksum issue here.  If this is the case, please go fix IPv6 by adding a hop by hop checksum extension header and getting it implemented by vendors.  ^_^

Please don't use UDP as a network layer.

See how easy that works?

> If by 'this' we mean stateful congestion control of multiple terabits of tunnel traffic, then it is *most certainly* not a solved problem, and definitely not something I'm interested in paying for.  

Oh, nobody wants to pay for anything, including (and especially) following standards. Fortunately, the IETF isn't an extension of an industrial company's marketing department (or isn't yet, I should say).

Joe


> 
> cheers,
>    -ed
> 
> 
> On Mon, Jan 27, 2014 at 11:24 AM, Joe Touch <touch@isi.edu> wrote:
> 
> 
> On 1/27/2014 11:19 AM, Joel M. Halpern wrote:
> Yes Joe, routers could ahve been built to do those calcualtions at that
> performance scale.
> There are however two major problems:
> 
> 1) That is not how routers are built.
> 2) The target performance scale is rather higher.
> 
> So could someone build an ASIC to do what you want?
> 
> Has. It's already part of nearly every DMA ASIC in a network interface already.
> 
> 
> > Probably.  Is there
> any reason in the world to expect operators to pay the significant extra
> cost for such?Not that I can see.
> 
> We're talking about a ring of full adders, the specs for which are given in an RFC that's 18 years old, and that is already implemented in nearly every host interface, including 10Gps NICs.
> 
> And we're talking about "routers", many variants of which operate at very high speeds and transparently proxy TCP already. So this is a solved problem.
> 
> 
> And even if we could and they would, that is not the world into which we
> are deploying these tunnels.
> 
> We're back to "that's not what they do now", at least in some devices.
> 
> Well, they don't use MPLS in UDP (since no spec exists), so clearly if they're limited to doing what they already do, this is an exercise in futility.
> 
> Joe
> 
> 
> 
> Yours,
> Joel
> 
> On 1/27/14 1:53 PM, Joe Touch wrote:
> 
> 
> On 1/27/2014 10:48 AM, joel jaeggli wrote:
> On 1/27/14, 8:48 AM, Joe Touch wrote:
> Those same mechanisms have provided hardware checksum support for a
> very long time.
> 
> The new header and the payload are actually in different parts of the
> forwarding complex until they hit the output queue, you can't checksum
> data you don't have.
> 
> You can (and some do) the checksum component parts when things go into
> memory; the partial sums can be added as the parts are combined in the
> output queue.
> 
> I appreciate that we're all taking about what might be done, but the
> reality is that there are many 'transparent TCP proxies' that have to do
> this, so there's clearly a solution, and it clearly runs fast enough.
> 
> Joe
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>