< draft-ietf-6lo-fragment-recovery-18.txt   draft-ietf-6lo-fragment-recovery-19.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4944 (if approved) 19 March 2020 Updates: 4944 (if approved) 20 March 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 20 September 2020 Expires: 21 September 2020
6LoWPAN Selective Fragment Recovery 6LoWPAN Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-18 draft-ietf-6lo-fragment-recovery-19
Abstract Abstract
This draft updates RFC 4944 with a simple protocol to recover This draft updates RFC 4944 with a protocol to forward individual
individual fragments across a route-over mesh network, with a minimal fragments across a route-over mesh and recover them end-to-end, with
flow control to protect the network against bloat. congestion control capabilities to protect the network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 20 September 2020. This Internet-Draft will expire on 21 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 15 6.1. Forwarding Fragments . . . . . . . . . . . . . . . . . . 15
6.1.1. Receiving the first fragment . . . . . . . . . . . . 15 6.1.1. Receiving the first fragment . . . . . . . . . . . . 15
6.1.2. Receiving the next fragments . . . . . . . . . . . . 16 6.1.2. Receiving the next fragments . . . . . . . . . . . . 16
6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16 6.2. Receiving RFRAG Acknowledgments . . . . . . . . . . . . . 16
6.3. Aborting the Transmission of a Fragmented Packet . . . . 17 6.3. Aborting the Transmission of a Fragmented Packet . . . . 17
6.4. Applying Recoverable Fragmentation along a Diverse 6.4. Applying Recoverable Fragmentation along a Diverse
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Path . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Management Considerations . . . . . . . . . . . . . . . . . . 18 7. Management Considerations . . . . . . . . . . . . . . . . . . 18
7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 19 7.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 19
7.2. Observing the network . . . . . . . . . . . . . . . . . . 21 7.2. Observing the network . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. Normative References . . . . . . . . . . . . . . . . . . . . 23 11. Normative References . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 25 12. Informative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 28
Appendix C. Considerations on Flow Control . . . . . . . . . . . 29 Appendix C. Considerations on Congestion Control . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
In most Low Power and Lossy Network (LLN) applications, the bulk of In most Low Power and Lossy Network (LLN) applications, the bulk of
the traffic consists of small chunks of data (on the order of a few the traffic consists of small chunks of data (on the order of a few
bytes to a few tens of bytes) at a time. Given that an IEEE Std. bytes to a few tens of bytes) at a time. Given that an IEEE Std.
802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or 802.15.4 [IEEE.802.15.4] frame can carry a payload of 74 bytes or
more, fragmentation is usually not required. However, and though more, fragmentation is usually not required. However, and though
this happens only occasionally, a number of mission critical this happens only occasionally, a number of mission critical
skipping to change at page 19, line 12 skipping to change at page 19, line 12
of losses, the observed variations of the round-trip time and the of losses, the observed variations of the round-trip time and the
setting of the ECN bit. setting of the ECN bit.
7.1. Protocol Parameters 7.1. Protocol Parameters
The management system SHOULD be capable of providing the parameters The management system SHOULD be capable of providing the parameters
listed in this section and an implementation MUST abide by those listed in this section and an implementation MUST abide by those
parameters and in particular never exceed the minimum and maximum parameters and in particular never exceed the minimum and maximum
configured boundaries. configured boundaries.
An implementation must control the rate at which it sends packets An implementation should consider the generic recommendations from
over the same path to allow the next hop to forward a packet before the IETF in the matter of congestion control and rate management for
it gets the next. In a wireless network that uses the same frequency IP datagrams in [RFC8085]. An implementation may perform a
along a path, more time must be inserted to avoid hidden terminal congestion control by using a dynamic value of the window size
issues between fragments (more in Section 4.2). An implementation (Window_Size), adapting the fragment size (Fragment_Size), and may
should consider the generic recommendations from the IETF in the reduce the load by inserting an inter-frame gap that is longer than
matter of congestion control and rate management in [RFC5033]. An necessary. In a large network where nodes contend for the bandwidth,
implementation may perform a congestion control by using a dynamic a larger Fragment_Size consumes less bandwidth but also reduces
value of the window size (Window_Size), adapting the fragment size fluidity and incurs higher chances of loss in transmission.
(Fragment_Size), and may reduce the load by inserting an inter-frame
gap that is longer than necessary. In a large network where nodes
contend for the bandwidth, a larger Fragment_Size consumes less
bandwidth but also reduces fluidity and incurs higher chances of loss
in transmission.
This is controlled by the following parameters: This is controlled by the following parameters:
inter-frame gap: Indicates the minimum amount of time between inter-frame gap: The inter-frame gap indicates the minimum amount of
transmissions. The inter-frame gap protects the propagation of time between transmissions. The inter-frame gap controls the rate
one transmission before the next one is triggered and creates a at which fragments are sent, the ratio of air time, and the amount
duty cycle that controls the ratio of air time and memory in of memory in intermediate nodes that a particular datagram will
intermediate nodes that a particular datagram will use. The use. It can be used as a flow control, a congestion control, and/
inter-frame gap controls the rate at which fragments are sent and or a collision control measure. It MUST be set at a minimum to a
SHOULD be selected large enough to protect the network. value that protects the propagation of one transmission against
collision with next [FRAG-FWD]. In a wireless network that uses
the same frequency along a path, this may represent the time for a
frame to progress over multiple hops (more in Section 4.2). It
SHOULD be augmented beyond this as necessary to protect the
network against congestion.
MinFragmentSize: The MinFragmentSize is the minimum value for the MinFragmentSize: The MinFragmentSize is the minimum value for the
Fragment_Size. It MUST be lower than the minimum value of Fragment_Size. It MUST be lower than the minimum value of
smallest 1-hop MTU that can be encountered along the path. smallest 1-hop MTU that can be encountered along the path.
OptFragmentSize: The OptFragmentSize is the value for the OptFragmentSize: The OptFragmentSize is the value for the
Fragment_Size that the fragmenting endpoint should use to start Fragment_Size that the fragmenting endpoint should use to start
with. It is greater than or equal to MinFragmentSize. It is less with. It is greater than or equal to MinFragmentSize. It is less
than or equal to MaxFragmentSize. For the first fragment, it must than or equal to MaxFragmentSize. For the first fragment, it must
account for the expansion of the IPv6 addresses and of the Hop account for the expansion of the IPv6 addresses and of the Hop
skipping to change at page 21, line 18 skipping to change at page 21, line 18
fragment. A default value of 3 is RECOMMENDED. An upper bound fragment. A default value of 3 is RECOMMENDED. An upper bound
can be estimated to ensure that the datagram is either fully can be estimated to ensure that the datagram is either fully
transmitted or dropped before an upper layer decides to retry it. transmitted or dropped before an upper layer decides to retry it.
MaxDatagramRetries: The maximum number of retries from scratch for a MaxDatagramRetries: The maximum number of retries from scratch for a
particular datagram. A default value of 1 is RECOMMENDED. An particular datagram. A default value of 1 is RECOMMENDED. An
upper bound can be estimated to ensure that the datagram is either upper bound can be estimated to ensure that the datagram is either
fully transmitted or dropped before an upper layer decides to fully transmitted or dropped before an upper layer decides to
retry it. retry it.
An implementation may be capable of performing flow control based on An implementation may be capable of performing congestion control
ECN; see in Appendix C. This is controlled by the following based on ECN; see in Appendix C. This is controlled by the following
parameter: parameter:
UseECN: Indicates whether the fragmenting endpoint should react to UseECN: Indicates whether the fragmenting endpoint should react to
ECN. The fragmenting endpoint may react to ECN by varying the ECN. The fragmenting endpoint may react to ECN by varying the
Window_Size between MinWindowSize and MaxWindowSize, varying the Window_Size between MinWindowSize and MaxWindowSize, varying the
Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or Fragment_Size between MinFragmentSize and MaxFragmentSize, and/or
by increasing or reducing the inter-frame gap. With this by increasing or reducing the inter-frame gap. With this
specification, if UseECN is set and a fragmenting endpoint detects specification, if UseECN is set and a fragmenting endpoint detects
a congestion, it may apply a congestion control method until the a congestion, it may apply a congestion control method until the
end of the datagram, whereas if UseECN is reset, the endpoint does end of the datagram, whereas if UseECN is reset, the endpoint does
skipping to change at page 21, line 43 skipping to change at page 21, line 43
7.2. Observing the network 7.2. Observing the network
The management system should monitor the number of retries and of ECN The management system should monitor the number of retries and of ECN
settings that can be observed from the perspective of both the settings that can be observed from the perspective of both the
fragmenting endpoint and the reassembling endpoint with regards to fragmenting endpoint and the reassembling endpoint with regards to
the other endpoint. It may then tune the optimum size of the other endpoint. It may then tune the optimum size of
Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize, Fragment_Size and of Window_Size, OptFragmentSize, and OptWindowSize,
respectively, at the fragmenting endpoint towards a particular respectively, at the fragmenting endpoint towards a particular
reassembling endpoint, applicable to the next datagrams. It will reassembling endpoint, applicable to the next datagrams. It will
preferably tune the inter-frame gap to increase the spacing between preferably tune the inter-frame gap to increase the spacing between
fragments of the same datagram and reduce the reduce the buffer bloat fragments of the same datagram and reduce the buffer bloat in
in intermediate node that holds one or more fragments of that intermediate node that holds one or more fragments of that datagram.
datagram.
8. Security Considerations 8. Security Considerations
This document specifies an instantiation of a 6FF technique and This document specifies an instantiation of a 6FF technique and
inherits from the generic description in [FRAG-FWD]. The inherits from the generic description in [FRAG-FWD]. The
considerations in the Security Section of [FRAG-FWD] equally apply to considerations in the Security Section of [FRAG-FWD] equally apply to
this document. this document.
In addition to the threats detailed therein, an attacker that is on- In addition to the threats detailed therein, an attacker that is on-
path can prematurely end the transmission of a datagram by sending a path can prematurely end the transmission of a datagram by sending a
skipping to change at page 25, line 46 skipping to change at page 25, line 38
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007, DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>. <https://www.rfc-editor.org/info/rfc4963>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/info/rfc5033>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
skipping to change at page 26, line 31 skipping to change at page 26, line 28
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007,
<https://www.rfc-editor.org/info/rfc5033>.
[LWIG-FRAG] [LWIG-FRAG]
Bormann, C. and T. Watteyne, "Virtual reassembly buffers Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf- in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
lwig-6lowpan-virtual-reassembly-01, 11 March 2019, lwig-6lowpan-virtual-reassembly-02, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan- <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
virtual-reassembly-01>. virtual-reassembly-02>.
[FRAG-ILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., [FRAG-ILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", Work and F. Gont, "IP Fragmentation Considered Fragile", Work
in Progress, Internet-Draft, draft-ietf-intarea-frag- in Progress, Internet-Draft, draft-ietf-intarea-frag-
fragile-17, 30 September 2019, fragile-17, 30 September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-frag- <https://tools.ietf.org/html/draft-ietf-intarea-frag-
fragile-17>. fragile-17>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
skipping to change at page 29, line 29 skipping to change at page 29, line 23
within the time boundary imposed by the recovery process of the within the time boundary imposed by the recovery process of the
Upper Layer Protocols. Upper Layer Protocols.
Optional congestion control: The aggregation of multiple concurrent Optional congestion control: The aggregation of multiple concurrent
flows may lead to the saturation of the radio network and flows may lead to the saturation of the radio network and
congestion collapse. congestion collapse.
The recovery mechanism should provide means for controlling the The recovery mechanism should provide means for controlling the
number of fragments in transit over the LLN. number of fragments in transit over the LLN.
Appendix C. Considerations on Flow Control Appendix C. Considerations on Congestion Control
Considering that a multi-hop LLN can be a very sensitive environment Considering that a multi-hop LLN can be a very sensitive environment
due to the limited queuing capabilities of a large population of its due to the limited queuing capabilities of a large population of its
nodes, this draft recommends a simple and conservative approach to nodes, this draft recommends a simple and conservative approach to
Congestion Control, based on TCP congestion avoidance. Congestion Control, based on TCP congestion avoidance.
Congestion on the forward path is assumed in case of packet loss, and Congestion on the forward path is assumed in case of packet loss, and
packet loss is assumed upon time out. The draft allows controlling packet loss is assumed upon time out. The draft allows controlling
the number of outstanding fragments that have been transmitted but the number of outstanding fragments that have been transmitted but
for which an acknowledgment was not received yet and are still for which an acknowledgment was not received yet and are still
skipping to change at page 30, line 5 skipping to change at page 29, line 47
Congestion Notification (ECN) mechanism. Though whether and how ECN Congestion Notification (ECN) mechanism. Though whether and how ECN
[RFC3168] is carried out over the LoWPAN is out of scope, this draft [RFC3168] is carried out over the LoWPAN is out of scope, this draft
provides a way for the destination endpoint to echo an ECN indication provides a way for the destination endpoint to echo an ECN indication
back to the fragmenting endpoint in an acknowledgment message as back to the fragmenting endpoint in an acknowledgment message as
represented in Figure 4 in Section 5.2. While the support of echoing represented in Figure 4 in Section 5.2. While the support of echoing
the ECN at the reassembling endpoint is mandatory, this specification the ECN at the reassembling endpoint is mandatory, this specification
only provides a minimalistic behaviour on the fragmenting endpoint, only provides a minimalistic behaviour on the fragmenting endpoint,
that is to reset the window to 1 so the fragments are sent and that is to reset the window to 1 so the fragments are sent and
acknowledged one by one till the end of the datagram. acknowledged one by one till the end of the datagram.
It must be noted that congestion and collision are different topics. It must be noted that though an inter-frame gap can be as a flow
control or a congestion control measure, collision avoidance is yet
another topic.
In particular, when a mesh operates on the same channel over multiple In particular, when a mesh operates on the same channel over multiple
hops, then the forwarding of a fragment over a certain hop may hops, then the forwarding of a fragment over a certain hop may
collide with the forwarding of the next fragment that is following collide with the forwarding of the next fragment that is following
over a previous hop but in the same interference domain. This draft over a previous hop but in the same interference domain. To prevent
enables end-to-end flow control, but leaves it to the fragmenting this, the fragmenting endpoint is required to pace individual
endpoint stack to pace individual fragments within a transmit window, fragments within a transmit window with an inter-frame gap. This is
so that a given fragment is sent only when the previous fragment has needed to ensure that a given fragment is sent only when the previous
had a chance to progress beyond the interference domain of this hop. fragment has had a chance to progress beyond the interference domain
In the case of 6TiSCH [I-D.ietf-6tisch-architecture], which operates of this hop. In the case of 6TiSCH [I-D.ietf-6tisch-architecture],
over the TimeSlotted Channel Hopping [RFC7554] (TSCH) mode of which operates over the TimeSlotted Channel Hopping [RFC7554] (TSCH)
operation of IEEE802.14.5, a fragment is forwarded over a different mode of operation of IEEE802.14.5, a fragment is forwarded over a
channel at a different time and it makes full sense to transmit the different channel at a different time and it makes full sense to
next fragment as soon as the previous fragment has had its chance to transmit the next fragment as soon as the previous fragment has had
be forwarded at the next hop. its chance to be forwarded at the next hop.
From the standpoint of a source 6LoWPAN endpoint, an outstanding From the standpoint of a source 6LoWPAN endpoint, an outstanding
fragment is a fragment that was sent but for which no explicit fragment is a fragment that was sent but for which no explicit
acknowledgment was received yet. This means that the fragment might acknowledgment was received yet. This means that the fragment might
be on the path, received but not yet acknowledged, or the be on the path, received but not yet acknowledged, or the
acknowledgment might be on the path back. It is also possible that acknowledgment might be on the path back. It is also possible that
either the fragment or the acknowledgment was lost on the way. either the fragment or the acknowledgment was lost on the way.
From the fragmenting endpoint standpoint, all outstanding fragments From the fragmenting endpoint standpoint, all outstanding fragments
might still be in the network and contribute to its congestion. might still be in the network and contribute to its congestion.
There is an assumption, though, that after a certain amount of time, There is an assumption, though, that after a certain amount of time,
a frame is either received or lost, so it is not causing congestion a frame is either received or lost, so it is not causing congestion
anymore. This amount of time can be estimated based on the round- anymore. This amount of time can be estimated based on the round-
trip time between the 6LoWPAN endpoints. For the lack of a more trip time between the 6LoWPAN endpoints. For the lack of a more
adapted technique, the method detailed in "Computing TCP's adapted technique, the method detailed in "Computing TCP's
Retransmission Timer" [RFC6298] may be used for that computation. Retransmission Timer" [RFC6298] may be used for that computation.
The reader is encouraged to read through "Congestion Control The reader is encouraged to read through "Congestion Control
Principles" [RFC2914]. Additionally [RFC7567] and [RFC5681] provide Principles" [RFC2914] and "Specifying New Congestion Control
Algorithms" [RFC5033]. Additionally [RFC7567] and [RFC5681] provide
deeper information on why this mechanism is needed and how TCP deeper information on why this mechanism is needed and how TCP
handles Congestion Control. Basically, the goal here is to manage handles Congestion Control. Basically, the goal here is to manage
the number of fragments present in the network; this is achieved by the number of fragments present in the network; this is achieved by
to reducing the number of outstanding fragments over a congested path to reducing the number of outstanding fragments over a congested path
by throttling the sources. by throttling the sources.
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
 End of changes. 20 change blocks. 
58 lines changed or deleted 61 lines changed or added

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