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

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 15:55:44 -0700

Hello,

I've posted a draft that describe a common header to use in UDP
surplus space (the bytes between the end of UDP payload and the end of
the IP packet). The header allows disambiguation between uses of the
UDP slack space, including possible non-standard uses via a required
checksum. The header includes a type field to allow different uses of
the surplus space. UDP options would be one use case, but the format
is extensible to allow other uses.

Tom

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Mar 11, 2019 at 3:49 PM
Subject: New Version Notification for draft-herbert-udp-space-hdr-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-udp-space-hdr-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-udp-space-hdr
Revision:       00
Title:          UDP Surplus Space Header
Document date:  2019-03-11
Group:          Individual Submission
Pages:          7
URL:
https://www.ietf.org/internet-drafts/draft-herbert-udp-space-hdr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-udp-space-hdr/
Htmlized:       https://tools.ietf.org/html/draft-herbert-udp-space-hdr-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-udp-space-hdr

Abstract:
   This draft defines a header for surplus space in UDP. The UDP surplus
   space is bytes between the end of the UDP payload and the end of the
   IP packet. The purpose of the header is to disambiguate uses of the
   surplus space. The UDP surplus space header includes a type, length,
   and checksum field that covers the space.

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.

The IETF Secretariat

---

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

> is extensible to allow other uses.

Notes from a quick glance.

The max length of 1020 would limit the current LITE+FRAG scheme for
sending a max ethernet (1500 byte) FRAG encoded mesage, but maybe
not a problem?

How would the CCO issue be addressed?
Especially so when multiple users of the surplus space are present,
since they'd have to be co-ordinated.

It does open up one other intersting posibility for the LITE alone
case, namely that could be its own surplus user (outside of UDP options),
encoded as the last surplus header:

 [ Type=LITE | Length = 1 | Checksum = fixed value ]

and then the rest of the bytes in the following surplus area would
comprise the LITE data.

Obviously this would suffer from the same deployment issues we've
been discussing wrt UDP-Options encoded LITE alone, but that might
just be something we'd have to live with.

It would mean that the LITE+FRAG case in UDP options could probably
be simplified to be one option alone.

DF

---

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

>  [ Type=LITE | Length = 1 | Checksum = fixed value ]

OK - that would be length = 0. I misread.

DF

---

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

> since they'd have to be co-ordinated.

Hmm - is this addressed by the fact that each surplus user would
checksums to zero?

If so, then combining this with a re-cast UDP-Options may well
make things simpler.

DF

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 17:12:22 -0700

> since they'd have to be co-ordinated.

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.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 17:12:54 -0700

> Hmm - is this addressed by the fact that each surplus user would

Yep :-)

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 17:33:00 -0700

> sending a max ethernet (1500 byte) FRAG encoded mesage, but maybe
I don't think the intent of the header would be to cover payload data,
just control data like options. That being said, there might be value
in having a checksum somewhere else in LITE+FRAG that would cover all
the payload. It's possible that we can get checksum offload to work
with that (we pretty much lost the value of it when UDP length is set
to 8 for LITE).

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Mar 2019 18:35:17 -0700

We already have more than sufficient TLV space in the current option definition to allow for other uses - or even other uses with their own sub-definitions - of the slack space.

I.e., if this is the direction we want to go, we can trivially go there with one KIND in the current system.

Joe

> On Mar 11, 2019, at 3:55 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
>