Subject: [tsvwg] UDP guidelines draft (5405bis) -07 - update

From: "Black, David" <[email-masked]>
Date: Mon, 23 Nov 2015 02:39:01 +0000

As WG chair: 

I think this version is reasonably good wrt my concerns, but I'd like to
hold it in the WG for a few weeks before making the publication request in
order to provide time for additional reviews (e.g., Erik Nordmark promised
to check this against the encapsulation draft in RTGWG).

<WG chair hat OFF>

The following text was added to help with the difficulties encountered in
dealing with UDP zero-checksum for IPv6:

		To protect	
 	      from misdelivery, new encapsulation designs SHOULD include an	
 	      integrity check at the transport layer that includes at least the	
 	      IPv6 header, the UDP header and the shim header for the	
 	      encapsulation, if any [RFC6936].	

I'd like to add a warning here to designers of what may happen if that SHOULD is
not followed, e.g. (borrowing some of RFC 2119's choice of words):

		Not including such a check can be expected to require significant
		effort to understand and carefully weigh the full implications
		and provide alternative assurances that misdelivery is unlikely.
		While this is possible (see Sections 3.1 and 3.2 of [RFC7510]
		for an example), use of an integrity check is RECOMMENDED.

Continuing (nit)
		
 	   o  One way to help satisfy the requirements of [RFC6936] may be to	
 	      limit the usage (e.g., to constrain traffic to an operator network
OLD
 	      Section 3.6, as in [RFC7510]).
NEW
		or set of closely cooperating networks, as further described in
		Section 3.6 below, see [RFC7510] for an example of this approach).

</WG chair hat OFF>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 23 Nov 2015 03:14:47 +0000 (UTC)

(Resending on this thread as subject references 5405bis,so it's more appropriate)
suggested alterations to the UDP-Lite section are attached.

Lloyd Wood [email-masked] http://about.me/lloydwood  

    On Monday, 23 November 2015, 13:39, "Black, David" <[email-masked]> wrote:

 As WG chair: 

<WG chair hat OFF>

        To protect    

Continuing (nit)

</WG chair hat OFF>

Thanks,
--David

---

From: Tom Herbert <[email-masked]>
Date: Sun, 22 Nov 2015 21:28:38 -0800

Hi Lloyd,

"Not having to compute a checksum across an entire IP packet can
decrease processing overhead and increase performance"-- This
statement should be qualified. As I mentioned, checksum offload in
NICs is already well deployed so that substituting UDP-Lite would
actually impact performance negatively in most existing deployments.

The one area where UDP-Lite potentially helps is for UDP encapsulation
(tunneling) as described in RFC6935 and RFC6936. This could be
interesting to devices that are unable to compute the full UDP
checksum. One potential problem with using UDP-Lite in this case is
that the range of the checksum field is unbounded (can be up to the
full length of the packet). The feedback we got form HW vendors in
"encapsulation considerations", was that this HW (like switches) can
only operate on some beginning portion of the packet (first 128 bytes
was suggested). I don't know see in UDP-LIte how to enforce a limit
the range of the checksum on input for these devices, I suppose this
would have to be a deployment limit or information conveyed out of
band.

Tom

---

From: <[email-masked]>
Date: Mon, 23 Nov 2015 05:44:42 +0000 (UTC)

Tom,

it's 'can' decrease processing overhead, not 'will' decreaseprocessing overhead. Any suggestions for qualification text?(We've already pointed out that existing middleboxes may notknow about UDP-Lite.)

UDP encapsulation is also discussed in RFC7510...

Yes, deciding how much you can cover and matching sender toreceiver capabilities is an out-of-band problem, as the texthints. There's nothing in the protocol, which was deliberatelydesigned to be a transparent(ish) upgrade to UDP, then ruined bythe protocol number decision.

I don't see how you can promote checksum offload andalso claim that devices are incapable of doing checksum offloadcan't do UDP checksum processing! Really, hardware implementationdetail; if we stuck with what hardware was limited by we'dbe claiming that IPv6 was infeasible because some generation ofCisco linecard FPGAs could only handle IPv4 headers and no larger.That some hardware is hardwired to UDP and can't do UDP-Liteoff the bat is not our problem. Think future.

So devices that offload checksumming to NICs aware of UDP-Liteare fine, and the devices that aren't fine just need to bereworked to offload UDP-Lite checksumming to NICs. Simple...

(Note not up to full length of packet - with jumbograms, first64K only. Jumbograms change the playing field somewhat.)

But in general, not having to do unneeded checksums at anintermediate layer (application checks its payload dataendtoend, e.g. Ethernet link CRCs cover links, Litecovers end-to-end demux) is a processing and time savingwin.
cheers
L.
 Lloyd Wood [email-masked] http://about.me/lloydwood  

    On Monday, 23 November 2015, 16:28, Tom Herbert <[email-masked]> wrote:

 Hi Lloyd,

Tom

---

From: "Black, David" <[email-masked]>
Date: Mon, 23 Nov 2015 15:28:36 +0000

Lloyd,

The proposed changes aren’t obvious from the attachment.

Could you send a marked up version of the text indicating the changes that you’re proposing?

Thanks,
--David

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 22, 2015 10:15 PM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

(Resending on this thread as subject references 5405bis,
so it's more appropriate)

Lloyd Wood [email-masked]<mailto:[email-masked]> http://about.me/lloydwood

On Monday, 23 November 2015, 13:39, "Black, David" <[email-masked]<mailto:[email-masked]>> wrote:

As WG chair:

<WG chair hat OFF>

        To protect

Continuing (nit)

</WG chair hat OFF>

Thanks,
--David
[email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754

---

From: Tom Herbert <[email-masked]>
Date: Mon, 23 Nov 2015 08:57:39 -0800

On Sun, Nov 22, 2015 at 9:44 PM,  <[email-masked]> wrote:
> Tom,
>
>
> it's 'can' decrease processing overhead, not 'will' decrease
> processing overhead. Any suggestions for qualification text?
> (We've already pointed out that existing middleboxes may not
> know about UDP-Lite.)
>
Maybe something like "UDP-Lite may be appropriate in cases where
computing the full UDP checksum is impractical or infeasible due to
processing constraints".

Another recommendation might be to reconsider default coverage length.
RFC3228 recommends that the default is to checksum over the entire
packet, but then this basically becomes UDP so why not just use UDP?
For the case of tunneling at least, maybe the recommendation should be
that the UDP-Lite checksum only covers the pseudo header and UDP
header, i.e. the minimum coverage to compensate for lack of IP header
checksum in IPv6.

> I don't see how you can promote checksum offload and
> also claim that devices are incapable of doing checksum offload
> can't do UDP checksum processing! Really, hardware implementation
> detail; if we stuck with what hardware was limited by we'd
> be claiming that IPv6 was infeasible because some generation of
> Cisco linecard FPGAs could only handle IPv4 headers and no larger.
> That some hardware is hardwired to UDP and can't do UDP-Lite
> off the bat is not our problem. Think future.
>
As I mentioned previously, RFC6935 and RFC6936 are concessions to
allow devices that cannot perform the UDP checksum calculation but
still want to source UDP. The concern of these is not hosts, but
switches that are performing tunneling over UDP. If this were just
about hosts there would be no issue since we already have the
necessary support for UDP checksums and neither the zero UDP checksum
in IPv6 nor UDP-Lite helps performance.

>
> So devices that offload checksumming to NICs aware of UDP-Lite
> are fine, and the devices that aren't fine just need to be
> reworked to offload UDP-Lite checksumming to NICs. Simple...
>
I think you would be hard pressed to find a NIC that supports UDP-Lite
checksum offload. Checksum offload logic is nearly identical for TCP
and UDP, UDP-Lite is actually more complexity. Besides that, we are
pushing vendors to get rid of protocol specific offloads (the fight
against protocol ossification). For instance, when receiving a packet
we prefer that a device just gives us the checksum as calculated over
the whole packet, it is then easy for the stack to apply that value to
verify any UDP, TCP, GRE checksums etc. in the packet (please look at
http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf).

Tom

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 06:14:41 +0000 (UTC)

David,

the changed text that I attached previously is a substantialchange of emphasis reusing text where it can, but the changeswill be obvious to an RFC5405bis draft author familiar withUDP-Lite  - which is to say, Gorry, who wrote RFC3828.

Gorry can take what he wants or needs from the suggested text.
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: "Black, David" <[email-masked]>
 To: "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>
 Sent: Tuesday, 24 November 2015, 2:28
 Subject: RE: [tsvwg] UDP guidelines draft (5405bis) -07 - update
   
#yiv5557487809 #yiv5557487809 -- _filtered #yiv5557487809 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv5557487809 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv5557487809 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5557487809 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5557487809 #yiv5557487809 p.yiv5557487809MsoNormal, #yiv5557487809 li.yiv5557487809MsoNormal, #yiv5557487809 div.yiv5557487809MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5557487809 a:link, #yiv5557487809 span.yiv5557487809MsoHyperlink {color:blue;text-decoration:underline;}#yiv5557487809 a:visited, #yiv5557487809 span.yiv5557487809MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5557487809 span.yiv5557487809EmailStyle17 {color:black;font-weight:normal;font-style:normal;text-decoration:none none;}#yiv5557487809 .yiv5557487809MsoChpDefault {font-size:10.0pt;} _filtered #yiv5557487809 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5557487809 div.yiv5557487809WordSection1 {}#yiv5557487809 Lloyd,    The proposed changes aren’t obvious from the attachment.    Could you send a marked up version of the text indicating the changes that you’re proposing?    Thanks,
--David    

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 22, 2015 10:15 PM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update    (Resending on this thread as subject references 5405bis, so it's more appropriate)    suggested alterations to the UDP-Lite section are attached.       Lloyd [email-masked] http://about.me/lloydwood        On Monday, 23 November 2015, 13:39, "Black, David" <[email-masked]> wrote:    As WG chair:

<WG chair hat OFF>

        To protect    

Continuing (nit)

</WG chair hat OFF>

Thanks,
--David

---

From: [email-masked]
Date: Thu, 26 Nov 2015 10:28:51 -0000

I'm going to get these soon and look at what I suggest could be included -
currently in the middle of another review and some final edits to another
draft.

Gorry

> David,
>
> the changed text that I attached previously is a substantialchange of
> emphasis reusing text where it can, but the changeswill be obvious to
> an RFC5405bis draft author familiar withUDP-Lite  - which is to say,
> Gorry, who wrote RFC3828.
>
> #yiv5557487809 #yiv5557487809 -- _filtered #yiv5557487809
> {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered
> #yiv5557487809 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;}
> _filtered #yiv5557487809 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2
> 4;} _filtered #yiv5557487809 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4
> 2 4;}#yiv5557487809 #yiv5557487809 p.yiv5557487809MsoNormal,
> #yiv5557487809 li.yiv5557487809MsoNormal, #yiv5557487809
> div.yiv5557487809MsoNormal
> {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5557487809 a:link,
> #yiv5557487809 span.yiv5557487809MsoHyperlink
> {color:blue;text-decoration:underline;}#yiv5557487809 a:visited,
> #yiv5557487809 span.yiv5557487809MsoHyperlinkFollowed
> {color:purple;text-decoration:underline;}#yiv5557487809
> span.yiv5557487809EmailStyle17
> {color:black;font-weight:normal;font-style:normal;text-decoration:none
> none;}#yiv5557487809 .yiv5557487809MsoChpDefault {font-size:10.0pt;}
> _filtered #yiv5557487809 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5557487809
> div.yiv5557487809WordSection1 {}#yiv5557487809 Lloyd,    The proposed
> changes aren’t obvious from the attachment.    Could you send a marked
> up version of the text indicating the changes that you’re proposing?   
> Thanks,
> --David   
>
> (Resending on this thread as subject references 5405bis, so it's more
> appropriate)    suggested alterations to the UDP-Lite section are
> attached.       Lloyd [email-masked]
> http://about.me/lloydwood        On Monday, 23 November 2015, 13:39,
> "Black, David" <[email-masked]> wrote:    As WG chair:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 30 Nov 2015 11:16:40 -0800

>                 for an example), use of an integrity check is RECOMMENDED.
I think this text is good and is consistent with section 14 in
draft-rtg-dt-encap-01. I'd also point out that mis-delivering packets
in a multi-tenant environment may not be innocuous at all, so I think
"carefully weigh the full implications" is an appropriate directive.

Tom

---

From: [email-masked]
Date: Mon, 30 Nov 2015 20:15:47 -0000

That's helpful, I'll include this.

Gorry