Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=us-ascii
From: Joe Touch <touch@isi.edu>
In-Reply-To: <201401280100.s0S10jhO097154@maildrop2.v6ds.occnc.com>
Date: Tue, 28 Jan 2014 08:49:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <16B434AA-C151-490D-98C2-DE052F464640@isi.edu>
References: <201401280100.s0S10jhO097154@maildrop2.v6ds.occnc.com>
To: curtis@ipv6.occnc.com
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
Precedence: list

On Jan 27, 2014, at 5:00 PM, Curtis Villamizar <curtis@ipv6.occnc.com> =
wrote:

>=20
> In message <52E6AB15.2080907@isi.edu>
> Joe Touch writes:
>=20
>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Joe
>=20
>=20
> Joe,
>=20
> Chips that did 4 x 10 Gb/s are old stuff now but in their day they
> pushed silicon limites.  Chips now do N x 100 Gb/s.

Yes, and it's 18 years later.=20

> Stewart is
> describing how these chips (both the prior generation and current) are
> architected and you are going back to some idea that there is a common
> memory where this all resides and its just a matter of looking at it.
> This is not software on a general purpose processor.

I never said software; I said that the checksum can be computed as the =
data moves (which is how we did it in 1996).

> If a queue forms, the headers are in SRAM and the body of the packet
> is off chip in DRAM.  There isn't enough memory bandwidth to pull the
> packet back until its time to send it out.  At that point the header
> and body are joined but the header processing has been completed long
> ago.

At some point the two come back together, at which point the partial =
sums of the header and body can be combined and inserted in the header.

...
> If there is no queue at all cut-through can happen.  The header gets
> transmitted before the entire packet arrives at the input of the
> chip.  (And if FCS fails a runt with bad FCS goes out).
>=20
> At the very least this can't work if cut-through is used to reduce
> latency.

Latency is a complex function of the bandwidth, propagation, coding, and =
processing delays, and there are very rare cases where cut-through =
reductions would impact E2E latency.=20

In those cases, there are other good reasons not to use UDP =
encapsulation.

> When the two are joined, about the only processing is in the
> MAC, its mostly loading a shift register and serializing but it also
> does the FCS and sticks that *at the end*.  The MAC is quite
> inflexible as it is mostly silicon gates designed to do some minimal
> processing for a layer-2 such as Ethernet or GFP/OTN.
>=20
> Think for a moment what N x 100 Gb/s means.  For small packets 150
> Mpps per interface with Ethernet overhead (large overhead).  That is
> 20 clock cycles per packet for a 3 GHz clock rate.  Divide that by N.
> This has to be done in specialized hardware

The hardware required is trivial, and easy to include in the same =
transfer mechanism used to move data (as it already has been for many =
years in network interfaces).

> BTW - "transparent TCP proxies" don't need to look at the payload for
> the purpose of updating a checksum.

That depends on whether the segments boundaries are preserved.

Joe=