At 05:23 AM 7/25/01 -0400, Ignatios Souvatzis wrote:
>> However, most if not all high-speed routers one encounters
>> today use silicon-based (ASICs and/or FPGAs) forwarders.
>> The nice thing about silicon is that lots of stuff can be
>> done in parallel. The IPv4 header checksum can be, and is,
>> calculated in parallel with the other header checks, etc,
>> that are going on. Thus, it takes 0.000000.... additional
>> time. If IPv6 had a header checksum, it too would be
>> calculated in 0.00000... additional time.
>
>you're aware that IPv6 has bigger headers, and additionally more likely
>to be variable length, than IPv4?
The basic forwarding decisions are all made in from the first,
basic, header. You know, the one with the addresses in it. For basic
forwarding, none of the other headers matter. The Routing header
is of interest, but if the routing header sees as much use as IPv4's
source routes, the hardware can ignore it.
>But even if hardware checksummers could
>checksum most v6 headers easily - a) you'd need new hardware,
But we need to develop new ASICs and FPGA images to support
IPv6 anyway, so adding hypothetical header checksumming would
be almost-0-added-cost for development and truly 0 added cost
for deployment. Of course, if the IPv6 development community
were to decide to add header checksums after IPv6-capable
ASICs and FPGAs were fielded, it would cost a lot.
>b) you'd penalize most software routers and endnodes,
That depends on how over-built the software systems are, doesn't
it? I mean, if the processor and data path and memory can handle
the load of checksumming without degrading overall system performance,
then there is no operational penalty, is there?
As to the cost on end-nodes, everything is relative. The cost
of a hypothetical IPv6 header checksum would be rather trivial
compared to the cost, say, of doing the TCP data checksum, which
can be over much, much, much, larger piles of bits.
>and c) needlessly, as most
>links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI,
>ARCnet, Token Ring, PPP, to name a few), so what's really needed is
>end-to-end checking, not hop-by-hop.
For the most part I agree. However, the link CRC does not
protect the packet while it is in a router's buffers or crosses
the various links within the router. So any error that might be
introduced there would be undetected. Some parts of the
hardware are pretty good -- for instance, error rates within
chips (i.e. when the packet is in the flipflops inside a chip)
are astronomically low. But at other places the rates can
be high -- in particular
- the high-speed (2+ghz) inter-chip links
- drams for buffers and stores of various kinds, and
- inter-board fabrics and backplanes
and those places do need protection. Good vendors will put in
parity and CRC and whatever to protect things, but that costs
added RAM, links, and so on, which means that costs are higher.
Vendors who are "cost sensitive", careless, or poorly educated,
might omit these protections. Thus, undetected errors can
creep in.
Then the questions are
- what are the error rates?
- how bad is it if one hits?
The answer to the first question is that the rates are fairly bad.
Any individual link, memory, etc, has a lowish rate, but due to the
quantity of them, the total rate for the box can be distressingly
high (the numbers depend on the box/design in question, of course).
The answer to the second question is less bad if the errors are
transient. Technically, if an occasional packet goes off to some
random place, it's no problem. But now we have data going to the
wrong place. That is generally frowned upon (for the sake of
argument, suppose that the packet has your ATM card number
and PIN in it ...).
A bigger technical problem is if the error is not transient,
that it's a 'stuck bit' someplace. Now, every packet goes wrong,
but the box does not know it, and can not report the failure.
You might wonder whether this protection is really relevant.
But I've met with enough customers and potential customers
to know that they ask very very detailed questions about a
router's internal data paths and EDAC and so on. They care.
>Anyway - it was designed to be that way when I was much younger (you could
>read about it in, err, was it Huitemas book 5 years ago?) and before
>I joined the business, so you discussing with me about this point today seems
>to be completely useless to me, as I can't and won't change it.
I am not trying to change the IPv6 design decision. The lack of
a header checksum is the least of the things I would consider
changing in V6. However, understanding some of the engineering
issues surrounding the implementation of a critical part of the
Internet infrastructure seems, to me anyway, to be A Good Thing.
Frank Kastenholz
Frank Kastenholz
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
