Subject: [nvo3] New Version Notification for draft-xiang-nvo3-geneve-packet-spray-00.txt

From: "Yuxiang (Yolanda)" <[email-masked]>
Date: Fri, 2 Mar 2018 23:28:25 +0000

Hi all,

We have submit a new draft about packet spraying in Geneve Overlay Network.

Really appreciate your comments and suggestions.

B.R.

Yolanda Yu

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2018年3月1日 16:27
收件人: Jianglong Wang <[email-masked]>; Yuxiang (Yolanda) <[email-masked]>; Xianghaizhou (A) <[email-masked]>; Paul Congdon <[email-masked]>
主题: New Version Notification for draft-xiang-nvo3-geneve-packet-spray-00.txt

A new version of I-D, draft-xiang-nvo3-geneve-packet-spray-00.txt

has been successfully submitted by Yolanda Yu and posted to the IETF repository.

Name:              draft-xiang-nvo3-geneve-packet-spray

Revision: 00

Title:                 Packet Spraying in Geneve Overlay Network

Document date:      2018-03-01

Group:              Individual Submission

Pages:              10

URL:           https://www.ietf.org/internet-drafts/draft-xiang-nvo3-geneve-packet-spray-00.txt

Status:         https://datatracker.ietf.org/doc/draft-xiang-nvo3-geneve-packet-spray/

Htmlized:       https://tools.ietf.org/html/draft-xiang-nvo3-geneve-packet-spray-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-xiang-nvo3-geneve-packet-spray-00

Abstract:

   Congestion is the killer of low latency and high throughput. Network

   congestion occurs on the interconnection links of a data center due

   to poor traffic distribution. Load balancing technologies are used to

   solve network congestion. Packet spraying is a kind of load balancing

   technology with finer granularity. This document describes a packet

   spraying protocol in the Geneve encapsulation network[1] using a

   newly defined Geneve Option field.

---

From: Dan Wing <[email-masked]>
Date: Sat, 3 Mar 2018 00:45:12 +0000

The paper "On the Impact of Packet Spraying in Data Center Networks" (*) shows impact of packet spraying with TCP and seems to show good results without the sequence number proposed in the Internet Draft.  Can the authors comment on that paper or on the need for the sequence number and group flow identifier, proposed in your I-D?

How would packet spraying impact or interwork with MPTCP, multipath QUIC, or multipath SCTP?

Section 5.3 ("TCP/UDP over Geneve") describes an optimization that avoids sending the inner IP header.  That optimization is not specific to packet spraying.  The optimization needs to be negotiated between the Geneve endpoints or configured using an SDN controller, which is not mentioned in Section 5.3.  Section 5.3 should be a separate I-D.

(*) "On the Impact of Packet Spraying in Data Center Networks", Advait Dixit, Pawan Prakash, Y. Charlie Hu, and Ramana Rao Kompella, https://pdfs.semanticscholar.org/4973/d22ad92fe2999f18cc57dd4a4cad81ba2cfe.pdf, 2013.

-d

> On Mar 2, 2018, at 3:28 PM, Yuxiang (Yolanda) <[email-masked]> wrote:
> 
> Hi all,
>  
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=lzwgWNbhPk9ZEri15eWdNoQQ8rlkWG0HmxGrFIiHAvU&s=l9vEhazIfnyEywSphRkHlAv9YRyB0UtxWO6x8RR1imo&e=

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 03 Mar 2018 22:32:36 -0500

Dan Wing <[email-masked]> writes:
> The paper "On the Impact of Packet Spraying in Data Center Networks"
> (*) shows impact of packet spraying with TCP and seems to show good
> results without the sequence number proposed in the Internet Draft.
> Can the authors comment on that paper or on the need for the sequence
> number and group flow identifier, proposed in your I-D?

I've heard people mention that if TCP uses timestamps, the effect of
packet reordering can be largely eliminated.  Is this actually true, and
if so, does anyone have a reference?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 03 Mar 2018 23:08:45 -0500

> Section 5.3 ("TCP/UDP over Geneve") describes an optimization that
> avoids sending the inner IP header.  That optimization is not specific
> to packet spraying.  The optimization needs to be negotiated between
> the Geneve endpoints or configured using an SDN controller, which is
> not mentioned in Section 5.3.  Section 5.3 should be a separate I-D.

draft-xiang-nvo3-geneve-packet-spray-00 handles putting a Layer 4
protocol (TCP or UDP) on top of Geneve by assigning new Ethertypes
(0x9004/9005).  A more elegant way is what I proposed last July:  Due to
the different types of Ethernet, Ethertypes are restricted to 0x0600 and
higher; the values 00 through 05 can't appear as the first byte.
(Though there actually are IEEE assignments in that range, there are
none with a high byte of 00.)  We can therefore modify the definition of
the "Protocol Type" field in the Geneve header such that if the first
byte is 00, then the second byte is the IP "protocol" value for the
contained packet.  That covers TCP, UDP, and all Layer 4 protocols
carried inside of IPv4/IPv6.

Dale

---

From: "Xianghaizhou (A)" <[email-masked]>
Date: Thu, 22 Mar 2018 06:55:00 +0000

This idea sound great, Did you propose any draft?

Regards.

-----邮件原件-----
发件人: Dale R. Worley [mailto:[email-masked]] 
发送时间: 2018年3月4日 12:09
收件人: Dan Wing
抄送: Yuxiang (Yolanda); [email-masked]; [email-masked]
主题: Re: [nvo3] New Version Notification for draft-xiang-nvo3-geneve-packet-spray-00.txt

> not mentioned in Section 5.3.  Section 5.3 should be a separate I-D.

draft-xiang-nvo3-geneve-packet-spray-00 handles putting a Layer 4 protocol (TCP or UDP) on top of Geneve by assigning new Ethertypes (0x9004/9005).  A more elegant way is what I proposed last July:  Due to the different types of Ethernet, Ethertypes are restricted to 0x0600 and higher; the values 00 through 05 can't appear as the first byte.
(Though there actually are IEEE assignments in that range, there are none with a high byte of 00.)  We can therefore modify the definition of the "Protocol Type" field in the Geneve header such that if the first byte is 00, then the second byte is the IP "protocol" value for the contained packet.  That covers TCP, UDP, and all Layer 4 protocols carried inside of IPv4/IPv6.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Mar 2018 23:27:24 -0400

> This idea sound great, Did you propose any draft?

No...  I suppose I should, just to have a fixed point to base the
discussion on.

BTW, looking at draft-xiang-nvo3-geneve-packet-spray-00, at the end of
section 5.3 is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|  Opt Len  |O|C|    Rsvd.  |          Protocol Type        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Virtual Network Identifier (VNI)       |    Reserved   |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Class = GFP           | Type=Capacity |R|R|R| Length=8|  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                           MAX GROUP ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                 Capability notification message format

In the third word, the "Length" field has the value 1, which indicates
that the option contains one word of option data.  Compare with the
figure at the end of section 5.1.

Also, the definition of MAX GROUP ID is

   MAX GROUP ID is a four byte field. MAX Group ID indicate the max
   Group ID assigned to the destination. The Group ID allocated by the
   source must be limited to 0 ~ MAX Group ID.

It might be more convenient to set "The Group ID allocated by the source
must be limited to 0 ~ (MAX Group ID - 1)."

Dale

---

From: Paul Congdon <[email-masked]>
Date: Fri, 23 Mar 2018 02:27:36 -0700

Dale,

I'm not sure your proposal is compatible with how the type/length field and
ethertype field are distinguished.  If the first octet is less than 0x06,
then the field is a type/length field per 802.3.

https://standards.ieee.org/develop/regauth/tut/ethertype.pdf

Paul

---

From: Paul Congdon <[email-masked]>
Date: Fri, 23 Mar 2018 02:28:08 -0700

Thanks for catching these.  They will get updated in the next revision.

Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 23 Mar 2018 22:47:54 -0400

> https://standards.ieee.org/develop/regauth/tut/ethertype.pdf

True, but there's no reason to put a packet length field in the Geneve
header; all ethertypes are 0x0600 or higher.  So we can give different
meanings to values of that field that start with 0x00-0x05

Dale

---

From: Paul Congdon <[email-masked]>
Date: Sat, 24 Mar 2018 05:55:48 +0000

Well,  not without breaking every asic implementation out there.