Subject: [nvo3] Fwd: New Version Notification for draft-herbert-remotecsumoffload-00.txt

From: Tom Herbert <[email-masked]>
Date: Tue, 26 Aug 2014 13:47:10 -0700

Remote checksum offload is intended to be used to get checksum offload
of encapsulated packets to work with legacy NICs (those that don't
understand encapsulation protocols). I will be posting an
implementation to Linux shortly for GUE and/or Geneve.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Aug 26, 2014 at 1:39 PM
Subject: New Version Notification for draft-herbert-remotecsumoffload-00.txt
To: Tom Herbert <[email-masked]>

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

Name:           draft-herbert-remotecsumoffload
Revision:       00
Title:          Remote checksum offload for encapsulation
Document date:  2014-08-27
Group:          Individual Submission
Pages:          9
URL:
http://www.ietf.org/internet-drafts/draft-herbert-remotecsumoffload-00.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-remotecsumoffload/
Htmlized:       http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00

Abstract:
   This specification describes remote checksum offload for
   encapsulation, which is a mechanism that provides checksum offload of
   encapsulated packets using rudimentary offload capabilities found in
   most Network Interface Card (NIC) devices. The outer header checksum
   (e.g. that in UDP or GRE) is enabled in packets and, with some
   additional meta information, a receiver is able to deduce the
   checksum to be set for an inner encapsulated packet. Effectively this
   offloads the computation of the inner checksum. Enabling the outer
   checksum in encapsulation has the additional advantage that it covers
   more of the packet than the inner checksum including the
   encapsulation headers.

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: Anton Ivanov <[email-masked]>
Date: Tue, 26 Aug 2014 22:09:22 +0100

> implementation to Linux shortly for GUE and/or Geneve.

This one was floated on the mailing list during the IETF-89 (and
immediately thereabouts) discussions around geneve, fixed/floating
headers, etc a while back.

We have had a working implementation for the GRE case for a while now
(we have it in a limited release product based around UML in customer
labs). I need to get around to contribute it upstream (in fact, I was
going to work on the patchsets this week).

The implementation for UDP based is trivial if you go for generic (not
protocol specific) checksum options in the linux kernel stack - as
discussed on the list 6 months ago. All you need is to implement the
IP_HDRINCL option for UDP in the kernel so you can get to the checksum.
After that you can use f.e. what we have contributed as a L2TPv3
direct-in-vNIC decaps driver for qemu (to ship in qemu-kvm 2.1) or the
legacy socket driver and extend it to use this option.

A.

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 26 Aug 2014 14:42:03 -0700

> going to work on the patchsets this week).
You extended GRE with fields for checksum offload?

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 26 Aug 2014 18:22:13 -0400

Code is king. I agree with what you said below.

Tom 

> On Aug 26, 2014, at 5:09 PM, Anton Ivanov <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 26 Aug 2014 15:27:01 -0700

However, deployed code is the kingdom.

Dino

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 27 Aug 2014 07:13:45 +0100

> You extended GRE with fields for checksum offload?

GRE has an optional checksum already as per RFC 2784 - nothing to extend.

If it is computed at source and checked by hardware or hypervisor at
destination you can compute the payload checksum from the GRE checksum
and pass it to the guest. It is an excellent reference example for your
idea because it can be implemented today using IP_HDRINCL which is not
yet possible for the UDP encaps as there is no sane way to get to the
header and get the csum from it for those without changing the kernel.
If nvGRE had the checksum specified (which it presently does not) it
could have been subjected to the same technique.

We discussed this in the context of CHECKSUM_COMPLETE vs
TCP/UDP/PROTOCOL_OF_CHOICE specific checksums 6 months ago and I wrote
exactly what you need to do to get remote checksums working at the time.
I was actually looking at sources at the time when writing that :)

If I have the time I will post the finalized UML driver sources on the
uml-devel list within a week and cc you.

A.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Aug 2014 07:43:33 -0700

> could have been subjected to the same technique.
I don't think we're talking about same thing. I think you're referring
to an offloading technique for receive side, which yes, can be done
without protocol change pretty easily. Remote checksum offload is
meant to offload the transmit checksum computation for encapsulation,
which I believe does need some protocol assistance.

---

From: "Anton Ivanov (antivano)" <[email-masked]>
Date: Wed, 27 Aug 2014 15:32:18 +0000

> which I believe does need some protocol assistance.

Either that or OOB control plane configuration which says for this 
Virtual Network Identifier and/or source compute all checksums, the 
frames are coming without ones. F.E. for gre key 0x012345678 compute the 
checksums before re-xmitting.

IMHO it is not strictly necessary to stick this into the protocol.

A.