Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-03.txt

From: [email-masked]
Date: Sun, 01 Jul 2018 22:33:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Transport Options for UDP
        Author          : Joe Touch
	Filename        : draft-ietf-tsvwg-udp-options-03.txt
	Pages           : 28
	Date            : 2018-07-01

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-03
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Touch <[email-masked]>
Date: Sun, 1 Jul 2018 23:36:36 -0700

Hi, all,

This adds all pending changes, notably:
- a few typos
- the LITE option for the 0-3 byte case
- renumbers the options for the following reason:
	- ensures that all the required options come first
- clarifies the computation of the CRC for ACS and OCS
- sections reordered to match the sequence assigned

The following has not changed:
- the options remain TLV, matching the way TCP options are parsed
- OCS remains optional

These details will be discussed in the second TSVWG session.

FYI - here’s a link to easily compare version 2 with the newest version 4:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-udp-options-02.txt?url2=draft-ietf-tsvwg-udp-options-04.txt

Joe

> On Jul 1, 2018, at 10:33 PM, [email-masked] wrote:
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Jul 2018 09:05:30 -0700

> - the options remain TLV, matching the way TCP options are parsed
Hi Joe,

Can you explain why OCS uses a one byte checksum instead of the
standard two byte ones' complement checksum used in IP. There is no
benefit to hosts for computing a one byte checksum (it's actually
slightly harder because an additional fold is needed), so the only
possible benefit I see is that it saves two bytes. Note that a one
byte checksum is substantially weaker than two bytes, so I'm not sure
that saving a couple of bytes is worth it.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Jul 2018 10:26:23 -0700

Hi Tom, 

Yeah - it was to make it 16-bit. Yes, it’s a lot weaker, but it’s also over a typically much smaller set of bytes.

We can make it longer if that’s consensus. I’ll add it to the discussion topics.

Joe

> On Jul 2, 2018, at 9:05 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 6 Jul 2018 16:16:11 +0100

> We can make it longer if that’s consensus. I’ll add it to the discussion topics.

Well I've mentioned in the past the my view that it should just use the common
16 bit 1s complement algorithm as used in the IP header, TCP header, UDP header.

DF

---

From: Joe Touch <[email-masked]>
Date: Sun, 8 Jul 2018 20:33:20 -0700

Hi, Derek,

The 8-bit variant uses the exact same algorithm as the 16-bit, except that it “folds” the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save space.

The only other comparable variant would be IPv4 (which isn’t used in IPv6); the TCP and UDP header checksums cover the payload as well as header, so they don’t quite correlate to the use we need.

Joe

> On Jul 6, 2018, at 8:16 AM, Derek Fawcus <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 9 Jul 2018 12:58:00 +0100

> The 8-bit variant uses the exact same algorithm as the 16-bit, except that it “folds” the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save…

With the proviso that one has to first parse the TLVs to determine the length,
or do it on the fly while parsing the TLVs, so one can't use the existing
implementation unless one goes for a two pass approach.

The other 'variable' in this is additional implentation complexity.
As to space, I view the existance of the FRAG option as significantly mitigating that.

> The only other comparable variant would be IPv4 (which isn’t used in IPv6); the TCP and UDP header checksums cover the payload as well as header, so they don’t quite correlate to the use we need.

What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP/IPv4 is identical.

DF

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Jul 2018 07:41:45 -0700

>> The 8-bit variant uses the exact same algorithm as the 16-bit, except that it “folds” the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save…

I don't see that saving a single byte is justified.

> implementation unless one goes for a two pass approach.
Also, it's usually good to process integrity checks and security
before other TLVs especially if they have side effects. As I mentioned
previously, a four byte fixed header for UDP options that includes
type (to differentiate different uses of UDP slack space), length, and
2 byte checksum addresses a lot of issues like this. Overhead of this
is about zero since the EOL option byte would be eliminated, and OCS
(type byte + one or two checksum bytes) is eliminated as well.

> What is covered differs, but the algorithm for TCP/UDP/UDP-Lite/DCCP/IPv4 is identical.
And the implementation for this particular algorithm has been heavily
optimized and it's been implemented in hardware many times over.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jul 2018 08:15:23 -0700

On 2018-07-09 07:41, Tom Herbert wrote:

> <[email-masked]> wrote: On Sun, Jul 08, 2018 at 08:33:20PM -0700, Joe Touch wrote: 
> The 8-bit variant uses the exact same algorithm as the 16-bit, except that it "folds" the result at the end. So the real question is whether we need 16 bits of protection or can tolerate 8 to save space.

 Also, it's usually good to process integrity checks and security
before other TLVs especially if they have side effects. As I mentioned
previously, a four byte fixed header for UDP options 

That is a completely separate issue that doesn't affect the difference
between a 1 and 2 byte OCS checksum. 
... 

> The only other comparable variant would be IPv4 (which isn't used in IPv6); the TCP and UDP header checksums cover the payload as well as header, so they don't quite correlate to the use we need. 

I am aware (RFC1936). Again, this doesn't change the algorithm. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jul 2018 08:25:27 -0700

FWIW, regarding the size of the fixed header... 

On 2018-07-09 07:41, Tom Herbert wrote:

> ...a four byte fixed header for UDP options that includes

TLV OCS would be either 2 bytes (ID and 1-byte sum) or 3 (ID and 2-byte
sum). It wouldn't necessarily need a length, though we could include it
anyway and make it 3 or 4 bytes, correspondingly. 

A fixed header as you propose would need to be at least the same length
- OCS (1 or 2 bytes) and 2 bytes for length (I don't think it's
appropriate to add option space and then needlessly constrain it). 

However, there's no "savings" per se of EOL; EOL is used *only* when the
sender extends the IP data area beyond where the current UDP header, UDP
payload, and UDP options extend. In currently expected cases, this would
not need to be present. 

Note that there's no "quick use" of OCS using length; we *have* to try
to parse the options anyway, otherwise we won't restore the option space
for LITE. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Jul 2018 09:47:43 -0700

On Mon, Jul 9, 2018 at 8:25 AM, Joe Touch <[email-masked]> wrote:
> A fixed header as you propose would need to be at least the same length -
> OCS (1 or 2 bytes) and 2 bytes for length (I don't think it's appropriate to
> add option space and then needlessly constrain it).
>
> payload, and UDP options extend. In currently expected cases, this would not
> need to be present.
>
> Note that there's no "quick use" of OCS using length; we *have* to try to
> parse the options anyway, otherwise we won't restore the option space for
> LITE.

Personally, I see no practical value in UDP LITE or including a
variant of it in UDP options. Every NIC being deployed today has
hardware capabilities to offload full UDP checksum, and there is zero
cost to the host stack to use that. Using LITE is actually a
complication that will be less efficient.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jul 2018 10:55:43 -0700

Keep in mind that LITE is key to making transparent frag/reassembly as
well, because LITE data is never interpreted as valid by hosts that
don't already support it (in this option's version of that capability). 

Joe