Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS)

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 24 Apr 2013 01:00:48 -0700

Martin Stiemerling has entered the following ballot position for
draft-ietf-core-coap-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A well-written document and I have a few points to discuss, but I still
need to write them in a comprehensive way. 

A tentative short list:

1) IPv6 UDP checksum calculation
It is not clear if zero UDP checksums are permitted or not permitted with
COAP.?
(UDP zero checksums: 
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/)
That should be specified. 

2) Handling of UDP-lite
Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with
CoAP?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Apr 2013 12:59:10 +0200

WG,

I think Martin's comment is interesting because I think we, as a WG, have never thought about this.
So let's have some discussion as a WG before the authors/chairs reply.

Background: IPv4 can "switch off" the UDP checksum by setting it to zero (= "not generated").
When IPv6 was designed, this capability was removed for two reasons:
-- The IP header checksum was removed in IPv6, and there was a feeling there should be at least some integrity protection of the header.
   This is provided by including the (pseudo-)header in the UDP checksum calculation (as it is in IPv4).
-- There was a general sentiment that switching off the UDP checksum in IPv4 had been occurring for all the wrong reasons, and there was operational experience with hard-to-find bugs caused by this (actually, my first activity on the university network here in Bremen in 1993 was finding a strange NFS hickup that, in the end, was caused exactly by this).

The backdrop for 6LoWPAN was, of course, IPv6, so when we designed the header compression there, we made sure that we preserved the UDP checksum.
There is some weasel-wording in 4.3.2 that allows "compressing" (eliding) the UDP checksum if this "is authorized by the upper layer".
This might make some sense with DTLS on top, which already provides its own integrity check.
(This doesn't guard against misdelivery, though.)
RFC 6282 also has no way to compress a zero checksum -- an elided checksum is just recomputed at the next hop.

So, with 6LoWPAN, we wouldn't easily get a 2-byte compression gain from UDPzero.

Now what about CoRE?

> https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/)

(That draft is in AUTH48 and will be RFC6936 soon.)	
This is a relatively new development, mostly motivated by tunneling in routers; I believe we are outside the scope of this RFC.

> That should be specified. 

I believe that is clearly specified by not referencing the udpzero draft.
In other words, for -15, it is not allowed.
(I'm ignoring the IPv4 case here, where we don't make a statement.)

But should it?
It mostly would save CPU, at least initially not space (see above).
It would remove one safety net that, in a world of somewhat unreliable and even haphazard devices, may be even more useful than it was in our campus network in 1993.

Other data points:
There is very little host support for UDPzero right now.
It is not clear how a node would decide to use UDPzero or not (would there have to be an indication in the URI?).

> Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with

UDPlite was an interesting extension of UDP to enable the use of UEP (unequal error protection) link layers:
Only part of the packet is protected with a checksum, so you get the data even if they are slightly corrupted in the unprotected space.
This is useful e.g. for speech.
To support this, UDPlite allows to "retract" the checksum by using the (otherwise redundant) length field to indicate the length of the protected space.

The considerations are similar, except that UDPlite support is even worse.
Hosts typically don't do it.
RFC 6282 can't NHC compress UDPlite as is (I think we even briefly discussed that and decided not to do it).
But most important, UEP link layers that are needed to make UDPlite really useful don't seem to exist in our space.

So:

What do you think?

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 24 Apr 2013 10:53:32 -0400

Hi Carsten,

Thanks for the good background and explanation.  My WG member feedback:

--- Snip-1 ---

AKBAR - YES, BUT I THINK MARTIN WANTS THE COAP-15 I-D TO EXPLICTILY MAKE THE STATEMENT OF SUPPORT OR NOT (FOR CLARITY).  AND ALSO, I GUESS, WE SHOULD HAVE SOME BRIEF TEXT DESCRIBING THE REASON FOR THE CHOICE.  THIS COULD, FOR EXAMPLE, BE DONE THROUGH A NEW "EXCEPTIONS" SECTION (ASSUMING THAT THE UDPZERO AND UDPLITE FEATURES ARE NOT SUPPORTED).

--- End Snip-1 -----

--- Snip-2 ---

Other data points:

AKBAR - INDICATING IT IN THE URI WOULD BE A REAL CROSS LAYER MESS IN MY OPINION!

--- End Snip-2 -----

Finally, on the main point about whether we should support the UDPZERO and UDPLITE, my vote would be to stick with our current approach (i.e. NOT support either of the two).  They seem to be specialized optimizations that are not well deployed and somehow seem to add overall deployment complexity and performance risk to the solution even if they provide some CPU reduction.

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday, April 24, 2013 6:59 AM
To: [email-masked] ([email-masked])
Subject: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss ondraft-ietf-core-coap-15: (with DISCUSS))

WG,

Now what about CoRE?

But should it?

Other data points:

So:

What do you think?

Grüße, Carsten

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Wed, 24 Apr 2013 17:55:19 +0300

> Finally, on the main point about whether we should support the UDPZERO and UDPLITE, my vote would be to stick with our current approach (i.e. NOT support either of the two).  They seem to be specia…

+1

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 24 Apr 2013 16:09:25 +0100

+1 on all comments made by Akbar.