< draft-li-tsvwg-loops-problem-opportunities-00.txt   draft-li-tsvwg-loops-problem-opportunities-01.txt >
TSVWG Y. Li TSVWG Y. Li
Internet-Draft X. Zhou Internet-Draft X. Zhou
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: September 6, 2019 March 05, 2019 Expires: September 12, 2019 March 11, 2019
LOOPS (Localized Optimization of Path Segments) Problem Statement and LOOPS (Localized Optimization of Path Segments) Problem Statement and
Opportunities Opportunities
draft-li-tsvwg-loops-problem-opportunities-00 draft-li-tsvwg-loops-problem-opportunities-01
Abstract Abstract
Various overlay tunnels are used in networks including WAN, Various overlay tunnels are used in networks including WAN,
enterprise campus and others. End to end paths are partitioned into enterprise campus and others. End to end paths are partitioned into
multiple segments using overlay tunnels to achieve better path multiple segments using overlay tunnels to achieve better path
selection, lower latency and so on. Traditional end-to-end transport selection, lower latency and so on. Traditional end-to-end transport
layers respond to packet loss slowly especially in long-haul layers respond to packet loss slowly especially in long-haul
networks: They either wait for some signal from the receiver to networks: They either wait for some signal from the receiver to
indicate a loss and then retransmit from the sender or rely on indicate a loss and then retransmit from the sender or rely on
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Cloud-Internet Overlay Network . . . . . . . . . . . . . . . 5 2. Cloud-Internet Overlay Network . . . . . . . . . . . . . . . 5
2.1. Tail Loss or Loss in Short Flows . . . . . . . . . . . . 7 2.1. Tail Loss or Loss in Short Flows . . . . . . . . . . . . 7
2.2. Packet Loss in Real Time Media Streams . . . . . . . . . 7 2.2. Packet Loss in Real Time Media Streams . . . . . . . . . 7
2.3. Packet Loss and Congestion Control in Bulk Data Transfer 8 2.3. Packet Loss and Congestion Control in Bulk Data Transfer 8
2.4. Multipathing . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Multipathing . . . . . . . . . . . . . . . . . . . . . . 8
3. Features and Impacts to be Considered for LOOPS . . . . . . . 9 3. Features and Impacts to be Considered for LOOPS . . . . . . . 9
3.1. Local Recovery and End-to-end Retransmission . . . . . . 9 3.1. Local Recovery and End-to-end Retransmission . . . . . . 10
3.1.1. OE to OE Measurement, Recovery and Multipathing . . . 11 3.1.1. OE to OE Measurement, Recovery and Multipathing . . . 12
3.2. Congestion Control Interaction . . . . . . . . . . . . . 12 3.2. Congestion Control Interaction . . . . . . . . . . . . . 12
3.3. Overlay Protocol Extensions . . . . . . . . . . . . . . . 13 3.3. Overlay Protocol Extensions . . . . . . . . . . . . . . . 14
3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . 14 6. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Overlay tunnels are widely deployed for various networks, including Overlay tunnels are widely deployed for various networks, including
long haul WAN interconnection, enterprise wireless access networks, long haul WAN interconnection, enterprise wireless access networks,
etc. The end to end connection is partitioned into multiple path etc. The end to end connection is partitioned into multiple path
segments using overlay tunnels. This serves a number of purposes, segments using overlay tunnels. This serves a number of purposes,
for instance, selecting a better path over the WAN or delivering the for instance, selecting a better path over the WAN or delivering the
packets over heterogeneous network, such as enterprise access and packets over heterogeneous network, such as enterprise access and
skipping to change at page 4, line 19 skipping to change at page 4, line 19
instance, loss detection and measurements. instance, loss detection and measurements.
LOOPS Node: Node supporting LOOPS functions. LOOPS Node: Node supporting LOOPS functions.
Overlay Node (ON): Node having overlay functions (like overlay Overlay Node (ON): Node having overlay functions (like overlay
protocol encapsulation/decapsulation, header modification, TLV protocol encapsulation/decapsulation, header modification, TLV
inspection) and LOOPS functions in LOOPS overlay network usage inspection) and LOOPS functions in LOOPS overlay network usage
scenario. Both OR and OE are Overlay Nodes. scenario. Both OR and OE are Overlay Nodes.
Overlay Tunnel: It specifies a tunnel with designated ingress and Overlay Tunnel: It specifies a tunnel with designated ingress and
egress nodes using some network overlay protocol as encapsulation. egress nodes using some network overlay protocol as encapsulation,
optionally with a specific traffic type.
Overlay Path: It specifies a channel within the overlay tunnel, and Overlay Path: It specifies a channel within the overlay tunnel, and
the traffic transmitted on the channel needs to pass through none the traffic transmitted on the channel needs to pass through none
or any number of designated intermediate overlay node. There may or any number of designated intermediate overlay node. There may
be more than one overlay path within an overlay tunnel when the be more than one overlay path within an overlay tunnel when the
different sets of designated intermediate overlay nodes are different sets of designated intermediate overlay nodes are
specified. An overlay path may contain multiple path segments. specified. An overlay path may contain multiple path segments.
When an overlay tunnel contains only one overlay path without any When an overlay tunnel contains only one overlay path without any
intermediate overlay node specified, overlay path and overlay intermediate overlay node specified, overlay path and overlay
tunnel are used interchangeably. tunnel are used interchangeably.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
| | | | | | | | | | | |
| | | /|\ | | | | | /|\ | |
+--------------------------------------------------+ +--------------------------------------------------+
| | | | | | | Internet | | | | | | | | Internet |
| o--o o---o->---o o---o->--o--o underlay | | o--o o---o->---o o---o->--o--o underlay |
+--------------------------------------------------+ +--------------------------------------------------+
Figure 2: Cloud-Internet Overlay Network (CION) Figure 2: Cloud-Internet Overlay Network (CION)
We tested based on 37 overlay nodes from multiple cloud providers We tested based on 37 overlay nodes from multiple cloud providers
globally [DOI_10.1109_ICNP.2018.00034]. Each pair of the overlay globally. Each pair of the overlay nodes are used as sender and
nodes are used as sender and receiver. When the traffic is not receiver. When the traffic is not intentionally directed to go
intentionally directed to go through any intermediate virtual nodes, through any intermediate virtual nodes, we call the path that the
we call the path that the traffic takes the _default path_ in the traffic takes the _default path_ in the test. When any of the
test. When any of the virtual nodes is intentionally used as an virtual nodes is intentionally used as an intermediate node to
intermediate node to forward the traffic, the path that the traffic forward the traffic, the path that the traffic takes is an _overlay
takes is an _overlay path_ in the test. The preliminary experiments path_ in the test. The preliminary experiments showed that the delay
showed that the delay of an overlay path is shorter than that of the of an overlay path is shorter than that of the default path in 69% of
default path in 69% of cases at 99% percentile and improvement is cases at 99% percentile and improvement is 17.5% at 99% percentile
17.5% at 99% percentile when we probe Ping packets every second for a when we probe Ping packets every second for a week.
week.
Lower delay does not necessarily mean higher throughput. Different Lower delay does not necessarily mean higher throughput. Different
path segments may have different packet loss rates. Loss rate is path segments may have different packet loss rates. Loss rate is
another major factor impacting TCP throughput. From some customer another major factor impacting TCP throughput. From some customer
requirements, we set the target loss rate to be less than 1% at 99% requirements, we set the target loss rate to be less than 1% at 99%
percentile and 99.9% percentile, respectively. The loss was measured percentile and 99.9% percentile, respectively. The loss was measured
between any two overlay nodes, i.e. any potential path segment. Two between any two overlay nodes, i.e. any potential path segment. Two
thousand Ping packets were sent every 20 seconds between two overlay thousand Ping packets were sent every 20 seconds between two overlay
nodes for 55 hours. This preliminary experiment showed that the nodes for 55 hours. This preliminary experiment showed that the
packet loss rate satisfaction are 44.27% and 29.51% at the 99% and packet loss rate satisfaction are 44.27% and 29.51% at the 99% and
skipping to change at page 9, line 37 skipping to change at page 9, line 37
3. Features and Impacts to be Considered for LOOPS 3. Features and Impacts to be Considered for LOOPS
LOOPS (Localized Optimization of Path Segments) tries to leverage the LOOPS (Localized Optimization of Path Segments) tries to leverage the
virtual nodes in a selected path to improve the transport performance virtual nodes in a selected path to improve the transport performance
"locally" instead of end-to-end as those nodes have partitioned the "locally" instead of end-to-end as those nodes have partitioned the
path to multiple segments. With the technologies like NFV (Network path to multiple segments. With the technologies like NFV (Network
function virtualization) and virtual IO, it is easier to add function virtualization) and virtual IO, it is easier to add
functions to virtual nodes and even the forwarding on those virtual functions to virtual nodes and even the forwarding on those virtual
nodes is getting more efficient. Some overlay protocols such as nodes is getting more efficient. Some overlay protocols such as
VXLAN [RFC7348], GENEVE [I-D.ietf-nvo3-geneve], LISP [RFC6830] or VXLAN [RFC7348], GENEVE [I-D.ietf-nvo3-geneve], LISP [RFC6830] or
CAPWAP [RFC5415] are assumed to be employed in the network. LOOPS is CAPWAP [RFC5415] are assumed to be employed in the network. In
expected to use sequence number space independent from that of the overlay network usage scenario, LOOPS can extend a specific overlay
transport layer. Acknowledgment should be used. To reduce overhead, protocol header to perform local measurement and local recovery
negative ACK over each path segment is a good choice here. functions, like the example shown in Figure 4.
Measurement over segment or overlay path is required to perform local
recovery. LOOPS does not look into the traffic payload. Elements to +------------+------------+---------------+---------+---------+
be considered in LOOPS are discussed briefly here. |Outer IP hdr|Overlay hdr |LOOPS extension|Inner hdr|payload |
+------------+------------+---------------+---------+---------+
Figure 4: LOOPS Extension Header Example
LOOPS uses packet number space independent from that of the transport
layer. Acknowledgment should be generated from ON receiver to ON
sender for packet loss detection and local measurement. To reduce
overhead, negative ACK over each path segment is a good choice here.
A Timestamp echo mechanism, analogous to TCP's Timestamp option,
should be employed in band in LOOPS extension to measure the local
RTT and variation for an overlay segment. Local in-network recovery
is performed. The measurement over segment is expected to give a
hint on whether the lost packet of locally recovered one was caused
by congestion. Such a hint could be further feedback, using like by
ECN Congestion Experienced (CE) markings, to the end host sender. It
directs the end host sender if congestion window adjustment is
necessary. LOOPS normally works on the overlay segment which
aggregates the same type of traffic, for instance TCP traffic or
finer granularity like TCP throughput sensitive traffic. LOOPS does
not look into the inner packet. Elements to be considered in LOOPS
are discussed briefly here.
3.1. Local Recovery and End-to-end Retransmission 3.1. Local Recovery and End-to-end Retransmission
There are basically two ways to perform local recovery, There are basically two ways to perform local recovery,
retransmission and FEC (forward error correction). They are possibly retransmission and FEC (forward error correction). They are possibly
used together in some cases. Such approaches between two overlay used together in some cases. Such approaches between two overlay
nodes recover the lost packet in relatively shorter distance and thus nodes recover the lost packet in relatively shorter distance and thus
shorter latency. Therefore the local recovery is always faster shorter latency. Therefore the local recovery is always faster
compared to end-to- end. compared to end-to- end.
skipping to change at page 11, line 23 skipping to change at page 11, line 46
o If LOOPS network does not buffer the out-of-order packets caused o If LOOPS network does not buffer the out-of-order packets caused
by packet loss, TCP sender can use a time based loss detection by packet loss, TCP sender can use a time based loss detection
like RACK [I-D.ietf-tcpm-rack] to prevent the TCP sender from like RACK [I-D.ietf-tcpm-rack] to prevent the TCP sender from
invoking the fast retransmit too early. RACK uses the notion of invoking the fast retransmit too early. RACK uses the notion of
time to replace the conventional DUPACK threshold approach to time to replace the conventional DUPACK threshold approach to
detect losses. RACK is required to be tuned to fit the local detect losses. RACK is required to be tuned to fit the local
retransmission better. If there are n segments over the path, retransmission better. If there are n segments over the path,
segment retransmission will at least add RTT/n to the reordering segment retransmission will at least add RTT/n to the reordering
window by average when the packet is lost only once over the whole window by average when the packet is lost only once over the whole
overlay path. This approach is more preferred than one described overlay path. This approach is more preferred than one described
in previous bullet. in previous bullet. On the other hand, if time based loss
detection is not supported at the sender, end to end
retransmission will be invoked as usual. It wastes some
bandwidth.
3.1.1. OE to OE Measurement, Recovery and Multipathing 3.1.1. OE to OE Measurement, Recovery and Multipathing
When local recovery is between two neighbor ONs, it is called per-hop When local recovery is between two neighbor ONs, it is called per-hop
recovery. It can be between overlay relays or between overlay relay recovery. It can be between overlay relays or between overlay relay
and overlay edge. Another type of local recovery is called OE to OE and overlay edge. Another type of local recovery is called OE to OE
recovery which performs between overlay edge nodes. When the recovery which performs between overlay edge nodes. When the
segments of an overlay path have similar characteristics and/or only segments of an overlay path have similar characteristics and/or only
OE has the expected processing capability, OE to OE based local OE has the expected processing capability, OE to OE based local
recovery can be used instead of per-hop recovery. recovery can be used instead of per-hop recovery.
skipping to change at page 12, line 52 skipping to change at page 13, line 28
There is a spectrum of approaches. On one end, each locally There is a spectrum of approaches. On one end, each locally
recovered packet can be treated exactly as a loss in order to invoke recovered packet can be treated exactly as a loss in order to invoke
the congestion control at the sender to guarantee the fair sharing as the congestion control at the sender to guarantee the fair sharing as
classic TCP by setting its CE (Congestion Experienced) bit. Explicit classic TCP by setting its CE (Congestion Experienced) bit. Explicit
Congestion Notification (ECN) can be used here as ECN marking was Congestion Notification (ECN) can be used here as ECN marking was
required to be equivalent to a packet drop [RFC3168]. Congestion required to be equivalent to a packet drop [RFC3168]. Congestion
control at the sender works as usual and no throughput improvement control at the sender works as usual and no throughput improvement
could be achieved (although the benefit of faster recovery is still could be achieved (although the benefit of faster recovery is still
there). On the other hand, ON can perform its congestion measurement there). On the other hand, ON can perform its congestion measurement
over the segment, for instance local RTT variation and throughput over the segment, for instance local RTT and its variation trend.
change trend. Then the lost packet can be determined if it was Then the lost packet can be determined if it was caused by congestion
caused by congestion or other factors. It will further decide if it or other factors. It will further decide if it is necessary to set
is necessary to set CE marking or even what ratio is set to make the CE marking or even what ratio is set to make the sender adjust the
sender adjust the sending rate more correctly. sending rate more correctly.
There are possible cases that the sender detects the loss even with There are possible cases that the sender detects the loss even with
local recovery in function. For example, when the re-ordering window local recovery in function. For example, when the re-ordering window
in RACK is not optimally adapted, the sender may trigger the in RACK is not optimally adapted, the sender may trigger the
congestion control at the same time of end-to-end retransmission. If congestion control at the same time of end-to-end retransmission. If
spurious retransmission detection based on DSACK [RFC3708] is used, spurious retransmission detection based on DSACK [RFC3708] is used,
such end-to-end retransmission will be found out unnecessary when such end-to-end retransmission will be found out unnecessary when
locally recovered packets reaches the receiver successfully. Then locally recovered packets reaches the receiver successfully. Then
congestion control changes might be undone at the sender. This congestion control changes will be undone at the sender. This
results in similar pros and cons as described earlier. Pros are results in similar pros and cons as described earlier. Pros are
preventing the necessary window reduction and improving the preventing the necessary window reduction and improving the
throughput when the loss is considered caused by non-persistent throughput when the loss is considered caused by non-persistent
congestion or random loss. Cons are some mechanisms like ECN or its congestion or random loss. Cons are some mechanisms like ECN or its
variants should be used wisely to make sure the congestion control is variants should be used wisely to make sure the congestion control is
invoked in case of persistent congestion. invoked in case of persistent congestion.
An approach where the losses on a path segment are not immediately An approach where the losses on a path segment are not immediately
made known to the end-to-end congestion control can be combined with made known to the end-to-end congestion control can be combined with
a "circuit breaker" style congestion control on the path segment. a "circuit breaker" style congestion control on the path segment.
skipping to change at page 13, line 27 skipping to change at page 14, line 4
results in similar pros and cons as described earlier. Pros are results in similar pros and cons as described earlier. Pros are
preventing the necessary window reduction and improving the preventing the necessary window reduction and improving the
throughput when the loss is considered caused by non-persistent throughput when the loss is considered caused by non-persistent
congestion or random loss. Cons are some mechanisms like ECN or its congestion or random loss. Cons are some mechanisms like ECN or its
variants should be used wisely to make sure the congestion control is variants should be used wisely to make sure the congestion control is
invoked in case of persistent congestion. invoked in case of persistent congestion.
An approach where the losses on a path segment are not immediately An approach where the losses on a path segment are not immediately
made known to the end-to-end congestion control can be combined with made known to the end-to-end congestion control can be combined with
a "circuit breaker" style congestion control on the path segment. a "circuit breaker" style congestion control on the path segment.
When the usage of path segment by the overlay flow starts to become When the usage of path segment by the overlay flow starts to become
unfair, the path segment sends congestion signals up to the end-to- unfair, the path segment sends congestion signals up to the end-to-
end congestion control. This must be carefully tuned to avoid end congestion control. This must be carefully tuned to avoid
unwanted oscillation. unwanted oscillation.
In summary, local recovery can improve Flow Completion Time (FCT) by
eliminating tail loss in small flows. As it changes loss event to
out-of-order event in most cases to TCP sender, if TCP sender uses
loss based congestion control, there is some implication on the
throughput. We suggest ECN and spurious retransmission to be enabled
when local recovery is in use, it would give the desirable
throughput, i.e. when loss is caused by congestion, reduce congestion
window; otherwise keep sender's sending rate. We do not suggest to
use spurious retransmission alone together with local recovery as it
may cause the TCP sender falsely undo window reduction when
congestion occurs. If only ECN is enabled or neither ECN nor
spurious retransmission is enabled, the throughput with local
recovery in use is no much difference from that of the tradition TCP.
3.3. Overlay Protocol Extensions 3.3. Overlay Protocol Extensions
The overlay usually has no control over how packets are routed in the The overlay usually has no control over how packets are routed in the
underlying network between two overlay nodes, but it can control, for underlying network between two overlay nodes, but it can control, for
example, the sequence of overlay nodes a message traverses before example, the sequence of overlay nodes a message traverses before
reaching its destination. LOOPS assumes the overlay protocol can reaching its destination. LOOPS assumes the overlay protocol can
deliver the packets in such designated sequence. Most forms of deliver the packets in such designated sequence. Most forms of
overlay networking use some sort of "encapsulation". The whole path overlay networking use some sort of "encapsulation". The whole path
taken can be performed by stitching multiple short overlay paths, taken can be performed by stitching multiple short overlay paths,
like VXLAN[RFC7348], GENEVE [I-D.ietf-nvo3-geneve], or it can be a like VXLAN[RFC7348], GENEVE [I-D.ietf-nvo3-geneve], or it can be a
skipping to change at page 16, line 12 skipping to change at page 17, line 5
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[I-D.dukkipati-tcpm-tcp-loss-probe] [I-D.dukkipati-tcpm-tcp-loss-probe]
Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,
"Tail Loss Probe (TLP): An Algorithm for Fast Recovery of "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of
Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work
in progress), February 2013. in progress), February 2013.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-10 (work in progress), March 2019. nvo3-geneve-11 (work in progress), March 2019.
[I-D.ietf-tcpm-rack] [I-D.ietf-tcpm-rack]
Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK:
a time-based fast loss detection algorithm for TCP", a time-based fast loss detection algorithm for TCP",
draft-ietf-tcpm-rack-04 (work in progress), July 2018. draft-ietf-tcpm-rack-04 (work in progress), July 2018.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019. progress), February 2019.
[I-D.cardwell-iccrg-bbr-congestion-control] [I-D.cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
"BBR Congestion Control", draft-cardwell-iccrg-bbr- "BBR Congestion Control", draft-cardwell-iccrg-bbr-
congestion-control-00 (work in progress), July 2017. congestion-control-00 (work in progress), July 2017.
[DOI_10.1109_ICNP.2018.00034]
Gu, L., Ju, R., Xu, Z., Li, J., and F. Li, "LTSM:
Lightweight and Time Sliced Measurement for Link State",
2018 IEEE 26th International Conference on Network
Protocols (ICNP), DOI 10.1109/icnp.2018.00034, September
2018.
[DOI_10.1109_ICDCS.2016.49] [DOI_10.1109_ICDCS.2016.49]
Cai, C., Le, F., Sun, X., Xie, G., Jamjoom, H., and R. Cai, C., Le, F., Sun, X., Xie, G., Jamjoom, H., and R.
Campbell, "CRONets: Cloud-Routed Overlay Networks", 2016 Campbell, "CRONets: Cloud-Routed Overlay Networks", 2016
IEEE 36th International Conference on Distributed IEEE 36th International Conference on Distributed
Computing Systems (ICDCS), DOI 10.1109/icdcs.2016.49, June Computing Systems (ICDCS), DOI 10.1109/icdcs.2016.49, June
2016. 2016.
Authors' Addresses Authors' Addresses
Yizhou Li Yizhou Li
 End of changes. 17 change blocks. 
48 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/