My follow up on Elliot email.
/Magnus
--- Begin Message ---
Thanks Eliot,
I CC my co-author.
I would also request that you answer the last call on the 6man list with
the comments that you think are suitable for that list.
On 2012-12-11 18:00, Eliot Lear wrote:
> Hi Magnus,
>
> A few things to start with...
>
> First, having only a little to do with the doc, on my noisy little house
> line, I'm seeing an error rate of about 10^-7. It's not nothing, but
> compared to the DOS attacks I receive, (the other 10^7) it's not what I
> worry about ;-)
Sure, but if your background error rate would be persistent at for
example 10^-3 it would seriously reduced the maximum TCP flow rate. So,
although DoS or simply attack traffic using up a certain percentage of
your available connection, packet corruption rates will have persistent
effects on your traffic. And Zero UDP checksum with IPv6 also have some
other effects related to being able to avoid processing misdirected
traffic.
>
> The first paragraph of Section 3.1 seems rather dated. Quoting a study
> that took place 12 years ago relating to internal processing is probably
> stretching it a bit. I'm not saying it never happens, but it seems to
> be worth less text than you give it.
I wished we had a study that would be more recent for the same field.
However, when we discussed this on the mailing list we got some report
that indicates that the UDP checksum error rates the reporter saw on
their DNS server corruption rates higher than 10^-3. That indicates that
in some parts of the Internet we still have significant corruption
happening which isn't being link layers and detected by link layer CRCs.
Yes, other parts definitely see much lower rates and your 10^-7 is
probably not at all uncommon.
>
> Section 4:
>
> There is a style here to separate senders and receivers, but it's not
> really called out. You could eliminate a good number of the bullets by
> simply matching sender and receiver behavior in the same bullets.
Yes, but there are some cases where there is important differences. But,
maybe we should divide them up into Sender and Receiver.
>
> 1. Slight improvement on clarity:
>
> OLD:
>
> An IPv6 sending node MAY use a calculated RFC 2460 checksum for all
> datagrams that it sends.
>
> NEW:
>
> An IPv6 sending node MAY calculate a checksum for all datagrams it
> transmits, using the method described in Section 8.1 of [RFC2460].
Yes, that is a clear improvement.
>
> (4) seems to require per-packet configuration. That wasn't your intent,
> I'm sure. I think it's well covered by 3, and would suggest simply
> remove it.
It is exactly intended to be "per-packet" configuration. So, no it is
not redundant with 3. Possibly it should be baked into 3 to make clear
that it does require per packet capabilities.
cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
