draft-ietf-taps-minset-09.txt | draft-ietf-taps-minset-10.txt | |||
---|---|---|---|---|
TAPS M. Welzl | TAPS M. Welzl | |||
Internet-Draft S. Gjessing | Internet-Draft S. Gjessing | |||
Intended status: Informational University of Oslo | Intended status: Informational University of Oslo | |||
Expires: March 17, 2019 September 13, 2018 | Expires: March 22, 2019 September 18, 2018 | |||
A Minimal Set of Transport Services for End Systems | A Minimal Set of Transport Services for End Systems | |||
draft-ietf-taps-minset-09 | draft-ietf-taps-minset-10 | |||
Abstract | Abstract | |||
This draft recommends a minimal set of Transport Services offered by | This draft recommends a minimal set of Transport Services offered by | |||
end systems, and gives guidance on choosing among the available | end systems, and gives guidance on choosing among the available | |||
mechanisms and protocols. It is based on the set of transport | mechanisms and protocols. It is based on the set of transport | |||
features in RFC 8303. | features in RFC 8303. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
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 March 17, 2019. | This Internet-Draft will expire on March 22, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 45 ¶ | skipping to change at page 2, line 45 ¶ | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 22 | 10.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
Appendix A. The Superset of Transport Features . . . . . . . . . 24 | Appendix A. The Superset of Transport Features . . . . . . . . . 24 | |||
A.1. CONNECTION Related Transport Features . . . . . . . . . . 25 | A.1. CONNECTION Related Transport Features . . . . . . . . . . 25 | |||
A.2. DATA Transfer Related Transport Features . . . . . . . . 41 | A.2. DATA Transfer Related Transport Features . . . . . . . . 41 | |||
A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41 | A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 41 | |||
A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45 | A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 45 | |||
A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46 | A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
Appendix B. Revision information . . . . . . . . . . . . . . . . 47 | Appendix B. Revision information . . . . . . . . . . . . . . . . 47 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
1. Introduction | 1. Introduction | |||
Currently, the set of transport services that most applications use | Currently, the set of transport services that most applications use | |||
is based on TCP and UDP (and protocols that are layered on top of | is based on TCP and UDP (and protocols that are layered on top of | |||
them); this limits the ability for the network stack to make use of | them); this limits the ability for the network stack to make use of | |||
features of other transport protocols. For example, if a protocol | features of other transport protocols. For example, if a protocol | |||
supports out-of-order message delivery but applications always assume | supports out-of-order message delivery but applications always assume | |||
that the network provides an ordered bytestream, then the network | that the network provides an ordered bytestream, then the network | |||
stack can not immediately deliver a message that arrives out-of- | stack can not immediately deliver a message that arrives out-of- | |||
skipping to change at page 7, line 37 ¶ | skipping to change at page 7, line 37 ¶ | |||
an implementation over UDP is possible, and "T,U:" if an | an implementation over UDP is possible, and "T,U:" if an | |||
implementation over either TCP or UDP is possible. | implementation over either TCP or UDP is possible. | |||
4.1. CONNECTION Related Transport Features | 4.1. CONNECTION Related Transport Features | |||
ESTABLISHMENT: | ESTABLISHMENT: | |||
o T,U: Connect | o T,U: Connect | |||
o T,U: Specify number of attempts and/or timeout for the first | o T,U: Specify number of attempts and/or timeout for the first | |||
establishment message | establishment message | |||
o T,U: Disable MPTCP | ||||
o T: Configure authentication | o T: Configure authentication | |||
o T: Hand over a message to reliably transfer (possibly multiple | o T: Hand over a message to reliably transfer (possibly multiple | |||
times) before connection establishment | times) before connection establishment | |||
o T: Hand over a message to reliably transfer during connection | o T: Hand over a message to reliably transfer during connection | |||
establishment | establishment | |||
AVAILABILITY: | AVAILABILITY: | |||
o T,U: Listen | o T,U: Listen | |||
o T,U: Disable MPTCP | ||||
o T: Configure authentication | o T: Configure authentication | |||
MAINTENANCE: | MAINTENANCE: | |||
o T: Change timeout for aborting connection (using retransmit limit | o T: Change timeout for aborting connection (using retransmit limit | |||
or time value) | or time value) | |||
o T: Suggest timeout to the peer | o T: Suggest timeout to the peer | |||
o T,U: Disable Nagle algorithm | o T,U: Disable Nagle algorithm | |||
o T,U: Notification of Excessive Retransmissions (early warning | o T,U: Notification of Excessive Retransmissions (early warning | |||
below abortion threshold) | below abortion threshold) | |||
o T,U: Specify DSCP field | o T,U: Specify DSCP field | |||
o T,U: Notification of ICMP error message arrival | o T,U: Notification of ICMP error message arrival | |||
o T: Change authentication parameters | o T: Change authentication parameters | |||
o T: Obtain authentication information | o T: Obtain authentication information | |||
o T,U: Set Cookie life value | o T,U: Set Cookie life value | |||
o T,U: Choose a scheduler to operate between streams of an | o T,U: Choose a scheduler to operate between streams of an | |||
skipping to change at page 13, line 32 ¶ | skipping to change at page 13, line 35 ¶ | |||
always be authenticated -- if this is exposed as such, it creates an | always be authenticated -- if this is exposed as such, it creates an | |||
undesirable dependency on the transport protocol. For compatibility | undesirable dependency on the transport protocol. For compatibility | |||
with TCP, a transport system should only allow to configure complete | with TCP, a transport system should only allow to configure complete | |||
transport layer packets, including headers, IP pseudo-header (if any) | transport layer packets, including headers, IP pseudo-header (if any) | |||
and payload. | and payload. | |||
Security is discussed in a separate document | Security is discussed in a separate document | |||
[I-D.ietf-taps-transport-security]. The minimal set presented in the | [I-D.ietf-taps-transport-security]. The minimal set presented in the | |||
present document excludes all security related transport features | present document excludes all security related transport features | |||
from Appendix A: "Configure authentication", "Change authentication | from Appendix A: "Configure authentication", "Change authentication | |||
parameters", "Obtain authentication information" and and "Set Cookie | parameters", "Obtain authentication information" and "Set Cookie life | |||
life value" as well as "Specifying a key id to be used to | value" as well as "Specifying a key id to be used to authenticate a | |||
authenticate a message". | message". It also excludes security transport features not listed in | |||
Appendix A, including content privacy to in-path devices. | ||||
5.7. Packet Size | 5.7. Packet Size | |||
UDP(-Lite) has a transport feature called "Specify DF field". This | UDP(-Lite) has a transport feature called "Specify DF field". This | |||
yields an error message in case of sending a message that exceeds the | yields an error message in case of sending a message that exceeds the | |||
Path MTU, which is necessary for a UDP-based application to be able | Path MTU, which is necessary for a UDP-based application to be able | |||
to implement Path MTU Discovery (a function that UDP-based | to implement Path MTU Discovery (a function that UDP-based | |||
applications must do by themselves). The "Get max. transport-message | applications must do by themselves). The "Get max. transport-message | |||
size that may be sent using a non-fragmented IP packet from the | size that may be sent using a non-fragmented IP packet from the | |||
configured interface" transport feature yields an upper limit for the | configured interface" transport feature yields an upper limit for the | |||
skipping to change at page 14, line 39 ¶ | skipping to change at page 14, line 39 ¶ | |||
(Sending Data, Receiving Data, Errors). Here, the focus is on | (Sending Data, Receiving Data, Errors). Here, the focus is on | |||
connections that the transport system offers as an abstraction to the | connections that the transport system offers as an abstraction to the | |||
application, as opposed to connections of transport protocols that | application, as opposed to connections of transport protocols that | |||
the transport system uses. | the transport system uses. | |||
6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION | 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION | |||
A connection must first be "created" to allow for some initial | A connection must first be "created" to allow for some initial | |||
configuration to be carried out before the transport system can | configuration to be carried out before the transport system can | |||
actively or passively establish communication with a remote end | actively or passively establish communication with a remote end | |||
system. All configuration parameters in Section 6.2 can be used | system. As a configuration of the newly created connection, an | |||
initially, although some of them may only take effect when a | application can choose to disallow usage of MPTCP. Furthermore, all | |||
connection has been established with a chosen transport protocol. | configuration parameters in Section 6.2 can be used initially, | |||
Configuring a connection early helps a transport system make the | although some of them may only take effect when a connection has been | |||
right decisions. For example, grouping information can influence the | established with a chosen transport protocol. Configuring a | |||
transport system to implement a connection as a stream of a multi- | connection early helps a transport system make the right decisions. | |||
streaming protocol's existing association or not. | For example, grouping information can influence the transport system | |||
to implement a connection as a stream of a multi-streaming protocol's | ||||
existing association or not. | ||||
For ungrouped connections, early configuration is necessary because | For ungrouped connections, early configuration is necessary because | |||
it allows the transport system to know which protocols it should try | it allows the transport system to know which protocols it should try | |||
to use. In particular, a transport system that only makes a one-time | to use. In particular, a transport system that only makes a one-time | |||
choice for a particular protocol must know early about strict | choice for a particular protocol must know early about strict | |||
requirements that must be kept, or it can end up in a deadlock | requirements that must be kept, or it can end up in a deadlock | |||
situation (e.g., having chosen UDP and later be asked to support | situation (e.g., having chosen UDP and later be asked to support | |||
reliable transfer). As an example description of how to correctly | reliable transfer). As an example description of how to correctly | |||
handle these cases, we provide the following decision tree (this is | handle these cases, we provide the following decision tree (this is | |||
derived from Section 4.1 excluding authentication, as explained in | derived from Section 4.1 excluding authentication, as explained in | |||
skipping to change at page 23, line 24 ¶ | skipping to change at page 23, line 24 ¶ | |||
2007, <https://www.rfc-editor.org/info/rfc4895>. | 2007, <https://www.rfc-editor.org/info/rfc4895>. | |||
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common | [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common | |||
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, | Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, | |||
<https://www.rfc-editor.org/info/rfc4987>. | <https://www.rfc-editor.org/info/rfc4987>. | |||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | |||
June 2010, <https://www.rfc-editor.org/info/rfc5925>. | June 2010, <https://www.rfc-editor.org/info/rfc5925>. | |||
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application | ||||
Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, | ||||
March 2013, <https://www.rfc-editor.org/info/rfc6897>. | ||||
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet | [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet | |||
Technology Adoption and Transition (ITAT)", RFC 7305, | Technology Adoption and Transition (ITAT)", RFC 7305, | |||
DOI 10.17487/RFC7305, July 2014, | DOI 10.17487/RFC7305, July 2014, | |||
<https://www.rfc-editor.org/info/rfc7305>. | <https://www.rfc-editor.org/info/rfc7305>. | |||
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | |||
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | |||
<https://www.rfc-editor.org/info/rfc7413>. | <https://www.rfc-editor.org/info/rfc7413>. | |||
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, | [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, | |||
skipping to change at page 24, line 51 ¶ | skipping to change at page 25, line 7 ¶ | |||
is exhibited to an application could be implemented by using a | is exhibited to an application could be implemented by using a | |||
single stream of an SCTP association instead of mapping it to a | single stream of an SCTP association instead of mapping it to a | |||
complete SCTP association or TCP connection. This could be | complete SCTP association or TCP connection. This could be | |||
achieved by using more than one stream when an SCTP association is | achieved by using more than one stream when an SCTP association is | |||
first established (CONNECT.SCTP parameter "outbound stream | first established (CONNECT.SCTP parameter "outbound stream | |||
count"), maintaining an internal stream number, and using this | count"), maintaining an internal stream number, and using this | |||
stream number when sending data (SEND.SCTP parameter "stream | stream number when sending data (SEND.SCTP parameter "stream | |||
number"). Closing or aborting a connection could then simply free | number"). Closing or aborting a connection could then simply free | |||
the stream number for future use. This is discussed further in | the stream number for future use. This is discussed further in | |||
Section 5.2. | Section 5.2. | |||
o All transport features that are related to using multiple paths or | o With the exception of "Disable MPTCP", all transport features that | |||
the choice of the network interface were designated as | are related to using multiple paths or the choice of the network | |||
"automatable". Choosing a path or an interface does not depend on | interface were designated as "automatable". For example, "Listen" | |||
application-specific knowledge. For example, "Listen" could | could always listen on all available interfaces and "Connect" | |||
always listen on all available interfaces and "Connect" could use | could use the default interface for the destination IP address. | |||
the default interface for the destination IP address. | ||||
Finally, in three cases, transport features are aggregated and/or | Finally, in three cases, transport features are aggregated and/or | |||
slightly changed from [RFC8303] in the description below. These | slightly changed from [RFC8303] in the description below. These | |||
transport features are marked as "CHANGED FROM RFC8303". These do | transport features are marked as "CHANGED FROM RFC8303". These do | |||
not add any new functionality but just represent a simple refactoring | not add any new functionality but just represent a simple refactoring | |||
step that helps to streamline the derivation process (e.g., by | step that helps to streamline the derivation process (e.g., by | |||
removing a choice of a parameter for the sake of applications that | removing a choice of a parameter for the sake of applications that | |||
may not care about this choice). The corresponding transport | may not care about this choice). The corresponding transport | |||
features are automatable, and they are listed immediately below the | features are automatable, and they are listed immediately below the | |||
"CHANGED FROM RFC8303" transport feature. | "CHANGED FROM RFC8303" transport feature. | |||
skipping to change at page 26, line 21 ¶ | skipping to change at page 26, line 25 ¶ | |||
Protocols: TCP, SCTP | Protocols: TCP, SCTP | |||
Functional because this is closely related to potentially assumed | Functional because this is closely related to potentially assumed | |||
reliable data delivery for data that is sent before or during | reliable data delivery for data that is sent before or during | |||
connection establishment. | connection establishment. | |||
Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. | Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. | |||
Implementation over UDP: Do nothing (this is irrelevant in case of | Implementation over UDP: Do nothing (this is irrelevant in case of | |||
UDP because there, reliable data delivery is not assumed). | UDP because there, reliable data delivery is not assumed). | |||
o Obtain multiple sockets | o Obtain multiple sockets | |||
Protocols: SCTP | Protocols: SCTP | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the non-parallel usage of multiple paths to | |||
the same end host relates to knowledge about the network, not the | communicate between the same end hosts relates to knowledge about | |||
application. | the network, not the application. | |||
o Disable MPTCP | o Disable MPTCP | |||
Protocols: MPTCP | Protocols: MPTCP | |||
Automatable because the usage of multiple paths to communicate to | Optimizing because the parallel usage of multiple paths to | |||
the same end host relates to knowledge about the network, not the | communicate between the same end hosts can improve performance. | |||
application. | Whether to use this feature depends on knowledge about the network | |||
as well as application-specific knowledge (see Section 3.1 of | ||||
[RFC6897]). | ||||
Implementation: via a boolean parameter in CONNECT.MPTCP. | Implementation: via a boolean parameter in CONNECT.MPTCP. | |||
Implementation over TCP: Do nothing. | ||||
Implementation over UDP: Do nothing. | ||||
o Configure authentication | o Configure authentication | |||
Protocols: TCP, SCTP | Protocols: TCP, SCTP | |||
Functional because this has a direct influence on security. | Functional because this has a direct influence on security. | |||
Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. | Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. | |||
With TCP, this allows to configure Master Key Tuples (MKTs) to | With TCP, this allows to configure Master Key Tuples (MKTs) to | |||
authenticate complete segments (including the TCP IPv4 | authenticate complete segments (including the TCP IPv4 | |||
pseudoheader, TCP header, and TCP data). With SCTP, this allows | pseudoheader, TCP header, and TCP data). With SCTP, this allows | |||
to specify which chunk types must always be authenticated. | to specify which chunk types must always be authenticated. | |||
Authenticating only certain chunk types creates a reduced level of | Authenticating only certain chunk types creates a reduced level of | |||
skipping to change at page 29, line 15 ¶ | skipping to change at page 29, line 21 ¶ | |||
knowledge about the network and the Operating System, not the | knowledge about the network and the Operating System, not the | |||
application. | application. | |||
o Specify which IP Options must always be used | o Specify which IP Options must always be used | |||
Protocols: TCP, UDP(-Lite) | Protocols: TCP, UDP(-Lite) | |||
Automatable because IP Options relate to knowledge about the | Automatable because IP Options relate to knowledge about the | |||
network, not the application. | network, not the application. | |||
o Disable MPTCP | o Disable MPTCP | |||
Protocols: MPTCP | Protocols: MPTCP | |||
Automatable because the usage of multiple paths to communicate to | Optimizing because the parallel usage of multiple paths to | |||
the same end host relates to knowledge about the network, not the | communicate between the same end hosts can improve performance. | |||
application. | Whether to use this feature depends on knowledge about the network | |||
as well as application-specific knowledge (see Section 3.1 of | ||||
[RFC6897]). | ||||
Implementation: via a boolean parameter in LISTEN.MPTCP. | ||||
Implementation over TCP: Do nothing. | ||||
Implementation over UDP: Do nothing. | ||||
o Configure authentication | o Configure authentication | |||
Protocols: TCP, SCTP | Protocols: TCP, SCTP | |||
Functional because this has a direct influence on security. | Functional because this has a direct influence on security. | |||
Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. | Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. | |||
Implementation over TCP: With TCP, this allows to configure Master | Implementation over TCP: With TCP, this allows to configure Master | |||
Key Tuples (MKTs) to authenticate complete segments (including the | Key Tuples (MKTs) to authenticate complete segments (including the | |||
TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this | TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this | |||
allows to specify which chunk types must always be authenticated. | allows to specify which chunk types must always be authenticated. | |||
Authenticating only certain chunk types creates a reduced level of | Authenticating only certain chunk types creates a reduced level of | |||
skipping to change at page 31, line 31 ¶ | skipping to change at page 31, line 39 ¶ | |||
informing it of an impending functional event. | informing it of an impending functional event. | |||
Implementation: via ERROR.TCP. | Implementation: via ERROR.TCP. | |||
Implementation over UDP: do nothing (there is no abortion | Implementation over UDP: do nothing (there is no abortion | |||
threshold). | threshold). | |||
o Add path | o Add path | |||
Protocols: MPTCP, SCTP | Protocols: MPTCP, SCTP | |||
MPTCP Parameters: source-IP; source-Port; destination-IP; | MPTCP Parameters: source-IP; source-Port; destination-IP; | |||
destination-Port | destination-Port | |||
SCTP Parameters: local IP address | SCTP Parameters: local IP address | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the choice of paths to communicate between the | |||
the same end host relates to knowledge about the network, not the | same end hosts relates to knowledge about the network, not the | |||
application. | application. | |||
o Remove path | o Remove path | |||
Protocols: MPTCP, SCTP | Protocols: MPTCP, SCTP | |||
MPTCP Parameters: source-IP; source-Port; destination-IP; | MPTCP Parameters: source-IP; source-Port; destination-IP; | |||
destination-Port | destination-Port | |||
SCTP Parameters: local IP address | SCTP Parameters: local IP address | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the choice of paths to communicate between the | |||
the same end host relates to knowledge about the network, not the | same end host relates to knowledge about the network, not the | |||
application. | application. | |||
o Set primary path | o Set primary path | |||
Protocols: SCTP | Protocols: SCTP | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the choice of paths to communicate between the | |||
the same end host relates to knowledge about the network, not the | same end hosts relates to knowledge about the network, not the | |||
application. | application. | |||
o Suggest primary path to the peer | o Suggest primary path to the peer | |||
Protocols: SCTP | Protocols: SCTP | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the choice of paths to communicate between the | |||
the same end host relates to knowledge about the network, not the | same end hosts relates to knowledge about the network, not the | |||
application. | application. | |||
o Configure Path Switchover | o Configure Path Switchover | |||
Protocols: SCTP | Protocols: SCTP | |||
Automatable because the usage of multiple paths to communicate to | Automatable because the choice of paths to communicate between the | |||
the same end host relates to knowledge about the network, not the | same end hosts relates to knowledge about the network, not the | |||
application. | application. | |||
o Obtain status (query or notification) | o Obtain status (query or notification) | |||
Protocols: SCTP, MPTCP | Protocols: SCTP, MPTCP | |||
SCTP parameters: association connection state; destination | SCTP parameters: association connection state; destination | |||
transport address list; destination transport address reachability | transport address list; destination transport address reachability | |||
states; current local and peer receiver window size; current local | states; current local and peer receiver window size; current local | |||
congestion window sizes; number of unacknowledged DATA chunks; | congestion window sizes; number of unacknowledged DATA chunks; | |||
number of DATA chunks pending receipt; primary path; most recent | number of DATA chunks pending receipt; primary path; most recent | |||
SRTT on primary path; RTO on primary path; SRTT and RTO on other | SRTT on primary path; RTO on primary path; SRTT and RTO on other | |||
skipping to change at page 48, line 45 ¶ | skipping to change at page 49, line 10 ¶ | |||
WG -06: Fixed nits. | WG -06: Fixed nits. | |||
WG -07: Addressed Genart comments from Robert Sparks. | WG -07: Addressed Genart comments from Robert Sparks. | |||
WG -08: Addressed one more Genart comment from Robert Sparks. | WG -08: Addressed one more Genart comment from Robert Sparks. | |||
WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben | WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben | |||
Campbell, Benjamin Kaduk and Eric Rescorla. | Campbell, Benjamin Kaduk and Eric Rescorla. | |||
WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. | ||||
Authors' Addresses | Authors' Addresses | |||
Michael Welzl | Michael Welzl | |||
University of Oslo | University of Oslo | |||
PO Box 1080 Blindern | PO Box 1080 Blindern | |||
Oslo N-0316 | Oslo N-0316 | |||
Norway | Norway | |||
Phone: +47 22 85 24 20 | Phone: +47 22 85 24 20 | |||
Email: michawe@ifi.uio.no | Email: michawe@ifi.uio.no | |||
Stein Gjessing | Stein Gjessing | |||
End of changes. 22 change blocks. | ||||
40 lines changed or deleted | 59 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/ |