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

[Edward Crabbe <[e-mail]>]

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.  ^_^

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.

cheers,
   -ed


On Mon, Jan 27, 2014 at 11:24 AM, Joe Touch <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>  _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>