Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-udp-space-hdr-00.txt

From: "C. M. Heard" <[email-masked]>
Date: Mon, 11 Mar 2019 19:42:53 -0700

On Mon, 11 Mar 2019 17:12:22 -0700 Tom Herbert wrote:
> If I understand CCO correctly, the problem seems to be that some
> middle boxes incorrectly use the IP length instead of UDP length for
> checksum calculation. This seems to be both for the coverage of the
> UDP checksum as well as the length in the pseudo header. The first
> part is addressed since the checksum in the UDP surplus header sums to
> zero, so adding this to the checksum just over the UDP header and
> payload yields the same value. Determining that the IP length was used
> in the pseudo header would require an extra step. It seems like that
> could be done without any special options, just check the normal UDP
> checksum and if that fails add the checksum difference between the IP
> length and UDP length and see if that yields checksum zero.

The problem with that suggestion is that it does not permit a UDP
packet with a trailer to traverse middleboxes that validate the
checksum using the IP payload length instead of the UDP length.
That is the main problem that CCO was designed to solve. See

https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00

Mike Heard

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 12 Mar 2019 12:14:51 +0100

> checksum using the IP payload length instead of the UDP length.

Is it this case you refer to page 10:

   UDP Length Checksum, IP length Pseudoheader

and that the packet is dropped here because the device has
used the wrong value for the length field within the pseudo
header when summing it?  Also incidentally, that this device
does not sum over the surlus area?

If so I've failed to find that in the draft, and find it
difficult to tease such details out of the slides.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 12 Mar 2019 12:21:12 +0100

> does not sum over the surlus area?

Actually, if it didn't sum the surplus, we couldn't correct
for it, and so that would just be a case of no packets passing.

So maybe you're referring to section 3, para 2 of your draft?

DF

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 07:23:42 -0700

> https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00
Mike,

I see. The same effect can by had by using a two byte pseudo header in
the checksum that contains the difference between the IP length and
the UDP length.

So for the "cost" of a mandatory two byte checksum, we get:

- Detection of non-standard uses of the surplus space
- Detection of corrupted bits in the option space
- Middleboxes can calculate UDP checksum based on IP length with no
additional bits needed for adjustment value
- Detection that the IP length is corrupted or changed inflight
- Uniformity and reuse of checksum APIs in implementation with other
IP protocols that contain a checksum (IP, TCP, UDP, GRE)
- Compatibility with NIC checksum offload

Tom

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 12 Mar 2019 16:44:46 +0100

I do find I sort of like Tom's proposal, and hence splitting the
options use from the surplus use, it does seem to simplify a
lot by having two layers.

That is assuming the CCO issue can be addressed.  Maybe that would
just require consuming some space for a CCO surplus user of Tom's
proposal, parallel with the UDP Options?  i.e. 8 bytes as currently defined.

If we were to go with Tom's approach, I'd be inclined to steal some
bits from its type field, and give them to the length field.
That way we could have larger users, and possibly byte level
lengths.  Think Gb Ethernet, and 9k frames.

Also I think Tom's suggestion would not need its initial padding
for alignment (even as currently specified), since we already
discussed to deal with an embedded checksum field being out of
aligment with the UDP header start.

That said, I've not yet read though Mike's latest FRAG proposal,
so don't know how or if that may influence my view.

DF

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 11:02:01 -0700

> proposal, parallel with the UDP Options?  i.e. 8 bytes as currently defined.
Hi Derek,

I believe the CCO issue is addressed by including a pseudo header in
the checksum which is the difference between IP length and the UDP
length. No extra bits are needed.

> lengths.  Think Gb Ethernet, and 9k frames.
That is certainly possible. A 12 bit length field in 4 bytes units
allows up to 16348 byte length, and then gives four bytes to type
which should be sufficient.

> aligment with the UDP header start.
Since alignment bytes are unlikely to reduce available MTU, there's
really not cost to it. Four bytes is common alignment assumed for IP
protocols, and there's no need to deal with unaligned checksum
calculation.

The UDP options can also be simplified to require that all options
have length of four (and hence are aligned to four bytes). Most of the
options defined so far are already 4 bytes length, and OCS is the only
one less than four bytes, but that is no longer needed with the
surplus header checksum. This would also eliminate the need for
padding options and allow for options up to 1024 bytes in size since
the length can be expressed in units of four bytes.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 11:09:48 -0700

> options defined so far are already 4 bytes length, and OCS is the only

Length divisible by four that is...

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 12 Mar 2019 12:21:49 -0700

> the checksum that contains the difference between the IP length and

Yes. My sense from reading the draft is that the optimum approach would
be to incorporate this pseudo-header compensation for ***each*** section
separately. Basically, the total length for a section (including header
and pad bytes) would be included in the checksum. The pad bytes can be
ignored since they are required to be zero. This assumes that every
surplus octet is included in some section.

> - Compatibility with NIC checksum offload

Sounds correct to me. One cost: the LITE option is of no use under this
proposal, since the LITE data would be checksummed. That defeats the
purpose of LITE.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 13:01:27 -0700

Mike,

Actually, only the first surplus section needs the pseudo header
adjustment. Any other sectiosn sum to zero so that the net sum of the
payload section is the length difference. I'm not sure what "surplus
octet " means.

> proposal, since the LITE data would be checksummed. That defeats the
To handle that a surplus area could be defined for containg UDP
payload. The Type Specific data contains the UDP payload followed by
the four byte swapped value. To restore the UDP payload the swap needs
to be done and the UDP length needs
to be set-- UDP lengths aren't necessarily a multiple of four so to
handle that four different types can be defined.

An advantage of this method is that teh UDP payload is still covered
by a per packet checksum and is offloadable. This obviates the need
for a reassembly checksum (very expensive to compute).

Tom

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 12 Mar 2019 13:49:33 -0700

On Tue, Mar 12, 2019 at 1:01 PM Tom Herbert wrote:
> On Tue, Mar 12, 2019 at 12:22 PM C. M. Heard wrote:
> > My sense from reading the draft is that the optimum approach would
> > ignored since they are required to be zero.
>
> adjustment. Any other sections sum to zero so that the net sum of the

That's true, but it makes the rules for computing and validating the
checksum depend on where the section is. What I proposed makes
the processing for each section the same; each one can be prepared
and validated in the same way, without considering where it appears.

> > This assumes that every surplus octet is included in some section.
> I'm not sure what "surplus octet " means.

Let me rephrase, then:  I mean that no octets exist that are not part
of either UDP payload or some surplus section, or equivalently, that
there are no trailing octets that are not part of some surplus section.
Your asymmetric proposal does not have that requirement.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 14:11:41 -0700

Mike,

I'm not sure how to do that in every section. Can you give an
algorithm? It seems like to solve the OCC problem the checksum of the
whole surplus area has to add up to the bitwise "not" of the IP/UDP
length difference.

> Your asymmetric proposal does not have that requirement.
The only bytes not in the UDP payload or surplus section is the
padding between the end of UDP payload and first surplus space header
(up to three bytes). All bytes starting from the UDP heade are subject
to integrity check by either the UDP checksum for payload, the surplus
space header checksum for each section, and the padding bytes are
verified to be zero. Note that if UDP payload is in a surplus section
there can be up to three bytes of padding after the end of UDP payload
to get to four byte alignment. Those bytes are in a section and
covered by the checksum.

Tom

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 12 Mar 2019 22:15:27 +0100

On Tue, Mar 12, 2019 at 11:02:01AM -0700, Tom Herbert wrote:
> On Tue, Mar 12, 2019 at 8:45 AM Derek Fawcus <[email-masked]> wrote:

Every IP stack (be it for router or host) that I have worked on has
had to include code for handling IP packets aligned to arbitrary
boundaries.

Simply because one never knows what earlier forms of encapsulation
(particularly tunnels) may have caused a mis-alignment of the IP
header.

So we don't save anything, at most we end up with a fast path for
aligned, and a slow path for misaligned.  Even then there is (due
to caches) essentially no performance difference, so the general
case code is often left in place just for simplicity.

Once one has the general code, the cost for dealing with the unaligned
checksum is essentially zero - at most an extra byte swap within
a register.

So this only helps the sender, not the receiver.

DF

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 14:33:38 -0700

> So this only helps the sender, not the receiver.
Derek,

There has been A LOT of discussion on alignment in the network
development community over the years. Most modern architectures handle
unaligned accesses fairly well now, although even in x86 an unaligned
access that crosses page boundaries is still painful. But, then
there's there's SPARC :-). Poor engineers working on it have had it
pretty miserable at times... see
https://github.com/davem330/sparc/blob/master/Documentation/unaligned-memory-access.txt

Unless there's a specific reason otherwise, I believe it's best to
perpetuate the typical four byte alignment characteristic in IP
protocols.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 15:35:35 -0700

On 2019-03-12 14:33, Tom Herbert wrote:

> ...

The existing UDP options definition already allows alignment via padding
where desired, but doesn't force it (following the lead of TCP - options
do not force alignment). 

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 12 Mar 2019 15:38:41 -0700

> whole surplus area has to add up to the bitwise "not" of the IP/UDP

Yes. Just include the total length of each surplus section,
including the length of the header and the number of padding
bytes that precede it, as a pseudo-header for that section.

This works because the 16-bit twos complement sum of the
UDP length and that of all surplus sections -- in other words,
the IP length -- is the same as the 16-bit ones complement
sum. That in turn is true because the IP length is less than
or equal to 2^16 - 1, so the twos complement sum results
in no carry that needs to be propagated end-around.

So, in the following. let S1 … SN be the surplus section
lengths, including header and preceding pads. Let
UDP_Len be the conventional UDP Length, and
let IP_Len be the IP payload length. Then, using
ones complement arithmetic,

IP_Len = UDP_Len + S1 + … SN

or

IP_Len + (-UDP_Len) + (-S1) + … + (-SN) = 0

where (-x) is the ones complement of x.

But we included (-UDP_Len) in the UDP checksum,
(-S1) in the first section checksum, and so on.

I rely here on associativity of ones complement arithmetic.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 15:45:21 -0700

> (-S1) in the first section checksum, and so on.
Makes sense. I'll incorporate into next version of the draft.

> I rely here on associativity of ones complement arithmetic.
It's always impressive how many ways we can exploit the properties of
checksum computation!

Thanks,
Tom

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 00:14:59 +0100

> It's always impressive how many ways we can exploit the properties of

Actually, I was thinking you could structure is somewhat like the
following, having hacked about your text.

DF

2  UDP surplus correction and data header formats

   The format of the UDP surplus correction header is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Padding (0 to 3 bytes)     |      CCO Corrective Word      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are:

      o Padding: Aligns the header to four bytes. The number of padding
        bytes required is: (((udp_length + 3) % 4) ^ 1) where the
        udp_length is the length of the UDP header and UDP payload.
        Padding bytes MUST be set to zero on transmission, and MUST be
        verified to be zero when received.

      o CCO Corrective Word: Difference between IP length and UDP length.

   The purpose of the correction header is to ensure the data header
   starts on a 4 byte boundary, and to correct for middleboxes which
   checksum the whole of the surplus area while also using a pseudo
   header with a length field being the IP packet length - IP header
   length, rather than the UDP length field.

   The format of the UDP surplus data header is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type |        Length         |         Checksum              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                      Type Specific Data                       ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are:

      o Type: The type of the UDP surplus space. Types are defined for
        UDP options, UDP Lite data, and Segmented UDP data.

      o Length: Length of the Type Specific Data in units of four byte
        words. The length of the Type Specific Data is thus zero to 16380
        bytes.

      o Checksum: The standard one's complement checksum that covers the
        UDP surplus data starting from the Type field through the end
        of the Type Specific Data as indicated in the Length field.

      o Type specific data: Data corresponding to the Type of the
        surplus data. For instance, in the case of UDP options, the Type
        specific data would contain the UDP options including any
        padding options to align the length of the Type Specific Data to
        four bytes.

   Defined Type values are:

      o 0: Reserved

      o 1: UDP options

      o 2: Segmented UDP

      o 3: Lite UDP

      o 4-13: Reserved

      o 14-15: Available for private use or experimentation

3  Operation

3.1 Sender operation

   A sender MAY set a UDP surplus correction header, a UDP surplus
   data header and data in the surplus space when sending a UDP packet.
   The UDP surplus correction header immediately follows the UDP payload
   at the offset of UDP Length from the start of the UDP header.  This
   is then followed by one or more UDP surplus data headers.

   The sender MUST insert up to three bytes of padding to align the UDP
   surplus data header to four bytes.

   The sender MUST set the Corrective Word field of the corrective
   header to the difference between the IP payload length
   (IP Total length - IP header length) and the UDP length.

   The sender MUST set the Type field to the type of the data to be
   processed.

[snip]

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 16:23:38 -0700

This proposal is a waste of space on more than one way. 

Again I ask - what problem is it trying to solve? 

Joe 

Specific issues: 

1. there's no need to align the CCO correction, as I've already shown 

2. there's no need for a separate checksum (it's redundant with the CCO
correction) 

3. there's no need for a type: 

- options are sufficient as defined in tsvwg-udp-options 

- the surplus area can be indicated by a new option (with a 2-byte
length) if we want to include it in the "CCO" (i.e., current OCS) sum 

- the surplus area can be indicated by EOL if it shouldn't be covered by
OCS (i.e., that's a choice) 

- LITE isn't needed as a category; it's already an option and we need
the ability to indicate swapped bytes (as already defined) to avoid
needing to copy portions over during reassembly 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 16:38:45 -0700

On Tue, Mar 12, 2019 at 4:23 PM Joe Touch <[email-masked]> wrote:
> 2. there's no need for a separate checksum (it's redundant with the CCO correction)
>
Again, why a separate checksum is needed.

Note all of this is done in two bytes, to get equivalent functionality
in UDP options you need a three byte OCs option and a four byte OCC
option = 7 bytes. I don't see how this is a waste of space.

> - the surplus area can be indicated by a new option (with a 2-byte length) if we want to include it in the "CCO" (i.e., current OCS) sum
>
> - the surplus area can be indicated by EOL if it shouldn't be covered by OCS (i.e., that's a choice)
>
> - LITE isn't needed as a category; it's already an option and we need the ability to indicate swapped bytes (as already defined) to avoid needing to copy portions over during reassembly
>
>
> Joe
>
>
>
>

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 01:48:51 +0100

> Again I ask - what problem is it trying to solve? 

I believe it simplifies the scenarios for handling the two
bulk data uses: Segmented data (FRAG+LITE), and Lite data,
removing them from the Options area, and as a consequence
also removing the need for the OCS option - as the checksum
in Tom's header would cover that.

We're comming up with increasingly complex encoding schemes
to try and shoehorn this in to the current options scheme,
and I see this as potentially cutting through that.

Hence why I'm exploring what could be achieved with Tom's
scheme.  I'll have a go at going over Mike's alternate
Frag scheme later.

As to use,  with this proposal we would do Segmentation by
sending a bunch of packets:

Pkt 1 | UDP Len = 0 | Seg data
...
Pkt n | UDP Len = 0 | Seg data | Options

The options then only being processed once the complete
set of segments have been reassembled.

i.e. process Tom's fields in order, then having got to the
Options, process that over the complete reassembled packet
(e.g. for ACS).

For Lite, I can see two possibilites:
  1) Accept that it is incompatible with middleboxes (or NICs)
     which require the CCO fix, then send in the obvious fashion:

Pkt: UDP Len = x (checksummed) | Lite data header | Lite data

i.e. have one surplus data header defining that lite data follows,
and then place the actual lite data in the tail of the surplus
area. Hence unchecksummed, the Lite data header indicating
that the processing of Tom's headers ceases, and the rest of
the packet is simply lite data.

  So in this scheme the Lite data header would have length of 0.

  Such problematic middleboxes (or NICs) will end up dropping
these packet.

  2) Try to do something using UDP CS = 0, and carry extra fields
to duplicate/restore the missing checksums.

Pkt: UDP Len = x (unchecked) | Lite data header | Lite data

  Here the lite data header would have some non zero length,
containing suffient fields to verify the non-lite portion
of the packet.  i.e. disconnected / moved checksums covering
the non-lite data and/or original pseudo-header.

  To combine that with additonal Options, one would probably
insert an Options region in front of the Lite data header.

Additionally,  I suspect for both of the above we could include
sufficient fields in the Lite data header such that the Lite
data itself could be segmented.

I doubt we'd want segmented non-lite data together with
segmented lite data, but could envisage having some
checksummed non-lite data followed by segmented lite data.

[There was a project I was involved with at a prior employer
 for which a scheme akin to that would have helped. We ended
 up using normal UDP and hence needlessly checksumming what
 could have been the segmented 'lite data'.

 The data to be segmented was essentially a tunneled packet,
 and so carried its own checksums/CRCs.  The non-lite data
 was meta-data about the packet which we did wish to be
 checksummed.
]

DF

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 01:53:49 +0100

> 1. there's no need to align the CCO correction, as I've already shown 

As to that, I know and agree.

However I consider that arguing that point with Tom is unimportant
at the moment, compared to exploring how the general approach of
this scheme stacks up.

DF

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 18:31:33 -0700

See below... 

> - Detection of non-standard uses of the surplus space

We should not be designing protocols to "detect" everything that *could*
happen, especially when it wouldn't affect us (i.e., this would be
needed only to detect surplus uses that aren't coordinated with us -
which, IMO, we should cover by fiat if we care) 

> - Detection of corrupted bits in the option space

That's already covered by OCS if used. 

> additional bits needed for adjustment value

But what if the IP and UDP lengths don't differ by the amount in the
length field?  

I don't see why we are passing information we already would need to
check anyway.  

> - Detection that the IP length is corrupted or changed inflight

That would break the IP checksum itself. 

> IP protocols that contain a checksum (IP, TCP, UDP, GRE)

These each have checksums in different places with different word
alignment, offsets, and different length fields (if at all). OCS as
spec'd is just as likely to use those APIs. 

> - Compatibility with NIC checksum offload

Same as above. 

> option = 7 bytes. I don't see how this is a waste of space.

It transmits information that needs to be checked anyway, which is a
waste. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 18:43:43 -0700

> in Tom's header would cover that.

I realize he wants to make OCS mandatory; it should not be. It wastes
space when not used (CS=0). 

Further, it won't help either of the two cases above EXCEPT if it
computes the checksum twice over those areas. 

That is extra, unnecessary (and important to reduce) work in the case of
FRAG+LITE. 

It is extra, deliberately undesired work in the case of LITE. 

I don't consider dumping all this stuff in one bag and doing extra work
"a simplification" at all. 

> and I see this as potentially cutting through that.

What's complex?  
- we added a value (IPlen - UDPlen) to the OCS computation 
- we wire LITE+FRAG to use CS=0  

That's a lot simpler than what's proposed. And a LOT less computation
PER PACKET. 

> ....

You forgot the headers, i.e.: 
Pkt x | UDP Len = 0 | requiredhdr | Sec data | options 

> set of segments have been reassembled.

That's already how FRAG+LITE works except for the byte swap. 

The proposal above would require moving the data around more; UDP 'zero
copy' (which can move payloads back-to-back separate from headers)
requires only a few bytes swapped per packet for FRAG+LITE; the proposal
above requires the data be recopied to move the segments together. 

Except that FRAG+LITE then requires the result be checksummed as a
whole. 

> Options, process that over the complete reassembled packet

ACS is much more work than the Internet checksum and may not be needed.
Simply doing fragmentation shouldn't force its use.  

Again, FRAG+LITE as proposed is just as simple if not simpler and less
work. 

> So in this scheme the Lite data header would have length of 0.

And you've just indicated that LITE packets can't allow other uses of
the remaining surplus area, which may be desired (and LITE as proposed
allows). 

> Such problematic middleboxes (or NICs) will end up dropping

The same result as the current LITE. 

> to duplicate/restore the missing checksums.

Any solution to that would undo the whole point of LITE. 

So, again, what's the point of all this? More work? Defeating the very
definition of LITE? 

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 19:20:09 -0700

On 2019-03-12 18:43, Joe Touch wrote:

> And you've just indicated that LITE packets can't allow other uses of the remaining surplus area, which may be desired (and LITE as proposed allows).

It occurs to me that the proposed header would also undermine the
current ability to use other options in addition to each individual
segment - in addition to the reassembled set as a whole. 

That might be useful, e.g., for timestamps, echo, or any of the other
current or to be proposed options. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 19:36:27 -0700

On Tue, Mar 12, 2019 at 6:31 PM Joe Touch <[email-masked]> wrote:
> We should not be designing protocols to "detect" everything that *could* happen, especially when it wouldn't affect us (i.e., this would be needed only to detect surplus uses that aren't coordinated with us - which, IMO, we should cover by fiat if we care)

I disagree. We need to design protocols to be robust. Per the
robustness principle, we need to accept "non-standard uses" of surplus
space and distinguish them.

> That's already covered by OCS if used.

It's not. As I pointed befire, the type can be corrupted so the OCS
disappears. The answer to that has been it can be required by a
receiver, but then that implies a negotiation between senders and
receivers. Maybe this can be done out of band in a limited domain, but
not in an Internet facing application talking to anonymous peers which
is really where the corruption detection is most important. A
mandatory checksum helps UDP options to be usable in the Internet.

> But what if the IP and UDP lengths don't differ by the amount in the length field?
>
The whole surplus space needs to be accounted for. It's up to the
sender to ensure the checksum works out.

> I don't see why we are passing information we already would need to check anyway.
>
>
>
Only for IPv4 (there is no checksum in IPv6) and it would detect the
case where the middlebox changed the length and updated the IPv4 csum.

> These each have checksums in different places with different word alignment, offsets, and different length fields (if at all). OCS as spec'd is just as likely to use those APIs.

Actually, no. The OCS is spec'ed as a one byte checksum, other
instances in IP protocols are two bytes. It's more work for both the
sender and receiver to compute a one byte checksum. Also about
checksums, having a reassembly checksum is not implementation
friendly. We can't offload such checksum to the NIC so this must be
done in the host CPU. It's much better to have a checksum per segment
that we can offload to the NIC and gives a mathematically equivalent
answer.

> - Compatibility with NIC checksum offload

See my note about offloading the reassembly checksum.

> It transmits information that needs to be checked anyway, which is a waste.

It think that is an overgeneralization. For example, if ends up that
OCS is used then that's three bytes (assuming a proper two byte
checksus is used) then we are wasting the type byte for OCS. And it
entails additional work, like required ordering of options. In any
case, we're talking a byte here and a byte, no UDP application is
going to care if a couple of lost bytes makes the protocol more
robust.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 23:21:05 -0400

Please recheck. I already changed everything except the diagram and summary table on this. It’s now CCO-equivalent. 

Joe 

> On Mar 12, 2019, at 10:36 PM, Tom Herbert <[email-masked]> wrote:
> 
> The OCS is spec'ed as a one byte checksum

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Mar 2019 20:32:51 -0700

> Please recheck. I already changed everything except the diagram and summary table on this. It’s now CCO-equivalent.

I'm missing something. Looking at draft-ietf-tsvwg-udp-options-07.txt
which seems to be latest version:

           2*      2         Option checksum (OCS)

Is that supposed to contain a two byte checksum now?

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 23:33:54 -0400

See 5.3. 

> On Mar 12, 2019, at 11:32 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 09:38:59 +0100

> 2. there's no need for a separate checksum (it's redundant with the CCO

[Morning now, rather than late night, so a bit more]

As to that (what I called the CCO Corrective Word), I see it serving
two main purposes.

1 - The CCO task of ensuring we can pass through one class of broken
    device. With Tom's scheme whereby the UDP Options are themselves
    in an optional section,  this word needs to live outwith the
    UDP options, at the same level as Tom's TLVs.

2 - It serves as a cheap 'signature' indicating that some packet doesn't
    actually follow Tom's proposal, i.e. is some legacy user of the
    surplus area.

So then the verification performed by the receiver would be similar to
what Tom described, but with an additional check quite early on that
the CCO Corrective Word has the proper value.  If not then the packet
is either corrupt, or doesn't abide by that spec.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 10:06:04 +0100

> segment - in addition to the reassembled set as a whole. 

Actually no, one could make it position dependent.

Options before Segment could be processed per packet on the wire,
the Options after the final Segment applying to the whole reassembled
packet.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 10:07:45 +0100

[snip]

Since you cover a lot of points in this main response, I'll have to
answer it a bit later.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 13 Mar 2019 10:21:40 +0100

[Another short response before tackling the big one]

> So, again, what's the point of all this? More work? Defeating the very

The point of UDP-Lite, and I rather understood the same for
the LITE option includes to send mixed data.  Some checksummed,
some not.

Using UDP CS=0 means that the portion which would have been
checksummed now is not.

My reference to 'carry extra fields' is related to ensuring that
the data portion one wants checked still is, while not covering
the portion which we want unchecked.  So no, I don't intend to
defeat the very point of LITE.

Also of course the coverage for the addresses and port numbers,
in the pseudo header portion of the checksum.
For the IPv6 case these would still be important, and probably
the destination portions are important even in the face of
IPv4 NATs.

I am assuming that the flawed NICs which miscalculate the length
in the UDP pseudo-header would also impact IPv6, even though that
hasn't been explicitly stated yet.

DF

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Mar 2019 07:58:49 -0700

Derek,

(So far) it looks like there are three ways that devices might be
computing the UDP checksum.

1. UDP length in pseudo header, checksum from start of UDP header for
UDP Length bytes
2. IP length in pseudo header, checksum from start of UDP header to
end of IP packet (CCO problem)
3. UDP length in packet, start from start of UDP header to the end of
the IP packet

#3 is how NIC checksum offload usually works and the checksum API, at
least for Linux, works. In the absence of surplus space all of these
work, and in fact have been working for years. If surplus space is
present, #2 continue works if the surplus area sums to the difference
in length between IP length and UDP, and #3 continues works if the
surplus area sums to zero. I'm not sure it's possible to
simultaneously satisfy the requirements of the #2 and #3 in the same
packet.

Tom

---

From: Raffaele Zullo <[email-masked]>
Date: Wed, 13 Mar 2019 15:16:41 +0000

> simultaneously satisfy the requirements of the #2 and #3 in the same

Hello,
Yes, our slides for maprg 103
(https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00 
)

showed these 3 cases.

Actually there's a 4th case.
IP Pay Length in the pseudoheader, checksum computed on UDP Length only.

Paths with 3rd and 4th checksum are quite rare, they are shown in the 
last slides.

As you said, 3rd CS can be compensated, with a regular internet 
checksum.

3rd and CCO (2nd) case cannot be compensated at the same time, unless 
Checksum(surplus length) is zero.

4th CS can't be compensated.

>> DF

FWIW all the NICs I have tested (not many) were accepting the 2nd (CCO) 
checksum

Raffaele Zullo

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Mar 2019 08:38:47 -0700

> 4th CS can't be compensated.
Hi Raffaele,

Thanks for the info. #4 is a good one indeed!

> FWIW all the NICs I have tested (not many) were accepting the 2nd (CCO)
For NICs that properly return the complete checksum of the whole
packet there won't be an issue since the host knows how to deal with
surplus space for checksum verification. Legacy NICs that explicitly
verify UDP checksum might have a problem if they do something other
than case #1. If they are failing to verify the checksum, it's likely
that the packet is sent to the host that performs it's own checksum
computation and verifies the packet. In that case packets are
accepted, but CPU load goes up.

Tom