[nvo3] FW: New Version Notification for draft-yu-nvo3-geneve-pkt-reordering-00.txt

[Yuxiang (Yolanda)]

Hi all,

In the previous draft-xiang-nvo3-geneve-packet-spray-00.txt draft, most of the contents focused on packet reordering.
We also got some comments from our group that this draft should be separated to 2 parts: packet spraying & packet reordering.
After integrating the comments or suggestions we received, a separate new draft was raised to cover packet reordering part as follows which replacing the previous one.
Packet spraying part may be left for new future cooperating with all the interested peoples.
Thank you for your comments on this.

B.R.
Yolanda Yu

-----Original Message-----
From: internet-***@ietf.org [mailto:internet-***@ietf.org]
Sent: Saturday, September 01, 2018 10:41 PM
To: Jianglong Wang <***@chinatelecom.cn>; Yuxiang (Yolanda) <***@huawei.com>
Subject: New Version Notification for draft-yu-nvo3-geneve-pkt-reordering-00.txt


A new version of I-D, draft-yu-nvo3-geneve-pkt-reordering-00.txt
has been successfully submitted by Yolanda Yu and posted to the IETF repository.

Name: draft-yu-nvo3-geneve-pkt-reordering
Revision: 00
Title: Packet Reordering in Geneve Overlay Network
Document date: 2018-09-01
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-yu-nvo3-geneve-pkt-reordering-00.txt
Status: https://datatracker.ietf.org/doc/draft-yu-nvo3-geneve-pkt-reordering/
Htmlized: https://tools.ietf.org/html/draft-yu-nvo3-geneve-pkt-reordering-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-yu-nvo3-geneve-pkt-reordering


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. During this situation, the packets
may arrive at the destination out of order. This document describes
a reordering protocol in the Geneve encapsulation network[1] using a
newly defined Geneve Option field.




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

[Dale R. Worley]

At a high level, this mechanism inserts a jitter-reordering buffer in
the flows of length OUTOFORDER_TIMER microseconds, where
OUTOFORDER_TIMER is a configured parameter. I have experience with
three different types of flow, each of which interacts with such a
mechanism in a different way:

UDP-based request/response protocols: These are insensitive to packet
reordering, and are only slowed down by dejittering.

TCP: I'm not an expert on TCP, but reports are that most TCP
congestion-control algorithms respond badly to misordered packet
reception. This seems to be a situation where jitter-reordering is
useful.

UDP-based media streaming (RTP): RTP receivers generally contain
dynamically-adjusted dejitter buffers. So I'd expect them to
automatically compensate for jitter introduced by packet spraying.
Adding dejittering upstream provides no additional value.

So it seems to me that doing jitter-reordering in a separate layer may
not be a good idea; rather it seems that OUTOFORDER_TIMER should be
provided to the transport layer so that it can compensate for packet
disordering.

Also, given that the similar mechanism for GRE is 18 years old, I'd like
to see the draft summarize experience with that mechanism.

Then again, there's no rule that the option has to be specified for all
packets between two endpoints. One possiblity is applying it only to
packets carrying TCP payloads. That allows the Geneve implementation to
support TCP implementations that don't respond well to packet
reordering, while leaving other implementations alone.

Dale