draft-ietf-taps-minset-06.txt | draft-ietf-taps-minset-07.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: February 23, 2019 August 22, 2018 | Expires: March 4, 2019 August 31, 2018 | |||
A Minimal Set of Transport Services for End Systems | A Minimal Set of Transport Services for End Systems | |||
draft-ietf-taps-minset-06 | draft-ietf-taps-minset-07 | |||
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 February 23, 2019. | This Internet-Draft will expire on March 4, 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 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. The Minimal Set of Transport Features . . . . . . . . . . . . 5 | 3. The Minimal Set of Transport Features . . . . . . . . . . . . 5 | |||
3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5 | 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5 | |||
3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8 | 3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8 | |||
3.2.2. Individual connections . . . . . . . . . . . . . . . 10 | 3.2.2. Individual connections . . . . . . . . . . . . . . . 10 | |||
3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10 | 3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10 | 3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10 | |||
3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11 | 3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11 | |||
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 7.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 13 | Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 14 | |||
Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15 | ||||
A.1. Step 1: Categorization -- The Superset of Transport | A.1. Step 1: Categorization -- The Superset of Transport | |||
Features . . . . . . . . . . . . . . . . . . . . . . . . 15 | Features . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
A.1.1. CONNECTION Related Transport Features . . . . . . . . 17 | A.1.1. CONNECTION Related Transport Features . . . . . . . . 17 | |||
A.1.2. DATA Transfer Related Transport Features . . . . . . 33 | A.1.2. DATA Transfer Related Transport Features . . . . . . 33 | |||
A.2. Step 2: Reduction -- The Reduced Set of Transport | A.2. Step 2: Reduction -- The Reduced Set of Transport | |||
Features . . . . . . . . . . . . . . . . . . . . . . . . 39 | Features . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 | A.2.1. CONNECTION Related Transport Features . . . . . . . . 39 | |||
A.2.2. DATA Transfer Related Transport Features . . . . . . 41 | A.2.2. DATA Transfer Related Transport Features . . . . . . 40 | |||
A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41 | A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 41 | |||
A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42 | A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 41 | |||
A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43 | A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 42 | |||
A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 | A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 43 | |||
A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44 | A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44 | |||
A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45 | A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 44 | |||
A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45 | A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 45 | |||
A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 | A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 45 | |||
Appendix B. Revision information . . . . . . . . . . . . . . . . 46 | Appendix B. Revision information . . . . . . . . . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
1. Introduction | 1. Introduction | |||
The task of a transport system is to offer transport services to its | Currently, the set of transport services that most applications use | |||
applications, i.e. the applications running on top of the transport | is based on TCP and UDP (and protocols that are layered on top of | |||
system. Ideally, it does so without statically binding applications | them); this limits the ability for the network stack to make use of | |||
to particular transport protocols. Currently, the set of transport | features of other transport protocols. For example, if a protocol | |||
services that most applications use is based on TCP and UDP (and | supports out-of-order message delivery but applications always assume | |||
protocols that are layered on top of them); this limits the ability | that the network provides an ordered bytestream, then the network | |||
for the network stack to make use of features of other transport | stack can not immediately deliver a message that arrives out-of- | |||
protocols. For example, if a protocol supports out-of-order message | order: doing so would break a fundamental assumption of the | |||
delivery but applications always assume that the network provides an | application. The net result is unnecessary head-of-line blocking | |||
ordered bytestream, then the network stack can not immediately | delay. | |||
deliver a message that arrives out-of-order: doing so would break a | ||||
fundamental assumption of the application. The net result is | ||||
unnecessary head-of-line blocking delay. | ||||
By exposing the transport services of multiple transport protocols, a | By exposing the transport services of multiple transport protocols, a | |||
transport system can make it possible to use these services without | transport system can make it possible for applications to use these | |||
having to statically bind an application to a specific transport | services without being statically bound to a specific transport | |||
protocol. The first step towards the design of such a system was | protocol. The first step towards the design of such a system was | |||
taken by [RFC8095], which surveys a large number of transports, and | taken by [RFC8095], which surveys a large number of transports, and | |||
[RFC8303] as well as [RFC8304], which identify the specific transport | [RFC8303] as well as [RFC8304], which identify the specific transport | |||
features that are exposed to applications by the protocols TCP, | features that are exposed to applications by the protocols TCP, | |||
MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control | MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control | |||
mechanism. This memo is based on these documents and follows the | mechanism. This memo is based on these documents and follows the | |||
same terminology (also listed below). Because the considered | same terminology (also listed below). Because the considered | |||
transport protocols conjointly cover a wide range of transport | transport protocols conjointly cover a wide range of transport | |||
features, there is reason to hope that the resulting set (and the | features, there is reason to hope that the resulting set (and the | |||
reasoning that led to it) will also apply to many aspects of other | reasoning that led to it) will also apply to many aspects of other | |||
transport protocols that may be in use today, or may be designed in | transport protocols that may be in use today, or may be designed in | |||
the future. | the future. | |||
The number of transport features of current IETF transports is large, | By decoupling applications from transport protocols, a transport | |||
and exposing all of them has a number of disadvantages: generally, | system provides a different abstraction level than the Berkeley | |||
the more functionality is exposed, the less freedom a transport | sockets interface. As with high- vs. low-level programming | |||
system has to automate usage of the various functions of its | languages, a higher abstraction level allows more freedom for | |||
available set of transport protocols. Some functions only exist in | automation below the interface, yet it takes some control away from | |||
one particular protocol, and if an application used them, this would | the application programmer. This is the design trade-off that a | |||
statically tie the application to this protocol, limiting the | transport system developer is facing, and this document provides | |||
flexibility of the transport system. Also, if the number of exposed | guidance on the design of this abstraction level. Some transport | |||
features is exceedingly large, a transport system might become very | features are currently rarely offered by APIs, yet they must be | |||
difficult to use for an application programmer. Taking [RFC8303] as | offered or they can never be used. Other transport features are | |||
a basis, this document therefore develops a minimal set of transport | offered by the APIs of the protocols covered here, but not exposing | |||
features, removing the ones that could get in the way of transport | them in an API would allow for more freedom to automate protocol | |||
flexibility but keeping the ones that must be retained for | usage in a transport system. The minimal set presented in this | |||
applications to benefit from useful transport functionality. | document is an effort to find a middle ground that can be recommended | |||
for transport systems to implement, on the basis of the transport | ||||
features discussed in [RFC8303]. | ||||
Applications use a wide variety of APIs today. The transport | Applications use a wide variety of APIs today. The transport | |||
features in the minimal set in this document must be reflected in | features in the minimal set in this document must be reflected in | |||
*all* network APIs in order for the underlying functionality to | *all* network APIs in order for the underlying functionality to | |||
become usable everywhere. For example, it does not help an | become usable everywhere. For example, it does not help an | |||
application that talks to a library which offers its own | application that talks to a library which offers its own | |||
communication interface if the underlying Berkeley Sockets API is | communication interface if the underlying Berkeley Sockets API is | |||
extended to offer "unordered message delivery", but the library only | extended to offer "unordered message delivery", but the library only | |||
exposes an ordered bytestream. Both the Berkeley Sockets API and the | exposes an ordered bytestream. Both the Berkeley Sockets API and the | |||
library would have to expose the "unordered message delivery" | library would have to expose the "unordered message delivery" | |||
skipping to change at page 6, line 8 ¶ | skipping to change at page 6, line 6 ¶ | |||
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 Appendix A.2.1 excluding authentication, as explained in | derived from Appendix A.2.1 excluding authentication, as explained in | |||
Section 7): | Section 6): | |||
- Will it ever be necessary to offer any of the following? | - Will it ever be necessary to offer any of the following? | |||
* Reliably transfer data | * Reliably transfer data | |||
* Notify the peer of closing/aborting | * Notify the peer of closing/aborting | |||
* Preserve data ordering | * Preserve data ordering | |||
Yes: SCTP or TCP can be used. | Yes: SCTP or TCP can be used. | |||
- Is any of the following useful to the application? | - Is any of the following useful to the application? | |||
* Choosing a scheduler to operate between connections | * Choosing a scheduler to operate between connections | |||
in a group, with the possibility to configure a priority | in a group, with the possibility to configure a priority | |||
skipping to change at page 12, line 13 ¶ | skipping to change at page 12, line 10 ¶ | |||
implemented to directly use TCP). | implemented to directly use TCP). | |||
Different from TCP's semantics, if the sending application has | Different from TCP's semantics, if the sending application has | |||
allowed that messages are not fully reliably transferred, or | allowed that messages are not fully reliably transferred, or | |||
delivered out of order, then such re-ordering or unreliability may be | delivered out of order, then such re-ordering or unreliability may be | |||
reflected per message in the arriving data. Messages will always | reflected per message in the arriving data. Messages will always | |||
stay intact - i.e. if an incomplete message is contained at the end | stay intact - i.e. if an incomplete message is contained at the end | |||
of the arriving data block, this message is guaranteed to continue in | of the arriving data block, this message is guaranteed to continue in | |||
the next arriving data block. | the next arriving data block. | |||
4. Conclusion | 4. Acknowledgements | |||
By decoupling applications from transport protocols, a transport | ||||
system provides a different abstraction level than the Berkeley | ||||
sockets interface. As with high- vs. low-level programming | ||||
languages, a higher abstraction level allows more freedom for | ||||
automation below the interface, yet it takes some control away from | ||||
the application programmer. This is the design trade-off that a | ||||
transport system developer is facing, and this document provides | ||||
guidance on the design of this abstraction level. Some transport | ||||
features are currently rarely offered by APIs, yet they must be | ||||
offered or they can never be used ("functional" transport features). | ||||
Other transport features are offered by the APIs of the protocols | ||||
covered here, but not exposing them in an API would allow for more | ||||
freedom to automate protocol usage in a transport system. The | ||||
minimal set presented in this document is an effort to find a middle | ||||
ground that can be recommended for transport systems to implement, on | ||||
the basis of the transport features discussed in [RFC8303]. | ||||
5. Acknowledgements | ||||
The authors would like to thank all the participants of the TAPS | The authors would like to thank all the participants of the TAPS | |||
Working Group and the NEAT and MAMI research projects for valuable | Working Group and the NEAT and MAMI research projects for valuable | |||
input to this document. We especially thank Michael Tuexen for help | input to this document. We especially thank Michael Tuexen for help | |||
with connection connection establishment/teardown and Gorry Fairhurst | with connection connection establishment/teardown, Gorry Fairhurst | |||
for his suggestions regarding fragmentation and packet sizes, and | for his suggestions regarding fragmentation and packet sizes, and | |||
Spencer Dawkins for his extremely detailed and constructive review. | Spencer Dawkins for his extremely detailed and constructive review. | |||
This work has received funding from the European Union's Horizon 2020 | This work has received funding from the European Union's Horizon 2020 | |||
research and innovation programme under grant agreement No. 644334 | research and innovation programme under grant agreement No. 644334 | |||
(NEAT). | (NEAT). | |||
6. IANA Considerations | 5. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
7. Security Considerations | 6. Security Considerations | |||
Authentication, confidentiality protection, and integrity protection | Authentication, confidentiality protection, and integrity protection | |||
are identified as transport features by [RFC8095]. As currently | are identified as transport features by [RFC8095]. As currently | |||
deployed in the Internet, these features are generally provided by a | deployed in the Internet, these features are generally provided by a | |||
protocol or layer on top of the transport protocol; no current full- | protocol or layer on top of the transport protocol; no current full- | |||
featured standards-track transport protocol provides all of these | featured standards-track transport protocol provides all of these | |||
transport features on its own. Therefore, these transport features | transport features on its own. Therefore, these transport features | |||
are not considered in this document, with the exception of native | are not considered in this document, with the exception of native | |||
authentication capabilities of TCP and SCTP for which the security | authentication capabilities of TCP and SCTP for which the security | |||
considerations in [RFC5925] and [RFC4895] apply. The minimum | considerations in [RFC5925] and [RFC4895] apply. The minimum | |||
requirements for a secure transport system are discussed in a | requirements for a secure transport system are discussed in a | |||
separate document (Section 5 on Security Features and Transport | separate document (Section 5 on Security Features and Transport | |||
Dependencies of [I-D.ietf-taps-transport-security]). | Dependencies of [I-D.ietf-taps-transport-security]). | |||
8. References | 7. References | |||
8.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-taps-transport-security] | ||||
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey | ||||
of Transport Security Protocols", draft-ietf-taps- | ||||
transport-security-02 (work in progress), June 2018. | ||||
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | ||||
Ed., "Services Provided by IETF Transport Protocols and | ||||
Congestion Control Mechanisms", RFC 8095, | ||||
DOI 10.17487/RFC8095, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8095>. | ||||
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of | [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of | |||
Transport Features Provided by IETF Transport Protocols", | Transport Features Provided by IETF Transport Protocols", | |||
RFC 8303, DOI 10.17487/RFC8303, February 2018, | RFC 8303, DOI 10.17487/RFC8303, February 2018, | |||
<https://www.rfc-editor.org/info/rfc8303>. | <https://www.rfc-editor.org/info/rfc8303>. | |||
8.2. Informative References | 7.2. Informative References | |||
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte | [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte | |||
Stuffing", September 1997, | Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No. | |||
<http://stuartcheshire.org/papers/COBSforToN.pdf>. | 2, April 1999. | |||
[I-D.ietf-taps-transport-security] | ||||
Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey | ||||
of Transport Security Protocols", draft-ietf-taps- | ||||
transport-security-01 (work in progress), May 2018. | ||||
[I-D.ietf-tsvwg-rtcweb-qos] | [I-D.ietf-tsvwg-rtcweb-qos] | |||
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP | |||
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- | |||
qos-18 (work in progress), August 2016. | qos-18 (work in progress), August 2016. | |||
[LBE-draft] | [LBE-draft] | |||
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", | Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", | |||
Internet-draft draft-tsvwg-le-phb-03, February 2018. | Internet-draft draft-tsvwg-le-phb-03, February 2018. | |||
skipping to change at page 14, line 33 ¶ | skipping to change at page 14, line 20 ¶ | |||
[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, | |||
"Additional Policies for the Partially Reliable Stream | "Additional Policies for the Partially Reliable Stream | |||
Control Transmission Protocol Extension", RFC 7496, | Control Transmission Protocol Extension", RFC 7496, | |||
DOI 10.17487/RFC7496, April 2015, | DOI 10.17487/RFC7496, April 2015, | |||
<https://www.rfc-editor.org/info/rfc7496>. | <https://www.rfc-editor.org/info/rfc7496>. | |||
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | ||||
Ed., "Services Provided by IETF Transport Protocols and | ||||
Congestion Control Mechanisms", RFC 8095, | ||||
DOI 10.17487/RFC8095, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8095>. | ||||
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, | |||
"Stream Schedulers and User Message Interleaving for the | "Stream Schedulers and User Message Interleaving for the | |||
Stream Control Transmission Protocol", RFC 8260, | Stream Control Transmission Protocol", RFC 8260, | |||
DOI 10.17487/RFC8260, November 2017, | DOI 10.17487/RFC8260, November 2017, | |||
<https://www.rfc-editor.org/info/rfc8260>. | <https://www.rfc-editor.org/info/rfc8260>. | |||
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the | [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the | |||
User Datagram Protocol (UDP) and Lightweight UDP (UDP- | User Datagram Protocol (UDP) and Lightweight UDP (UDP- | |||
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, | Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, | |||
<https://www.rfc-editor.org/info/rfc8304>. | <https://www.rfc-editor.org/info/rfc8304>. | |||
skipping to change at page 47, line 46 ¶ | skipping to change at page 47, line 28 ¶ | |||
that referred to it. | that referred to it. | |||
WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As | WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As | |||
part of that, removed "TAPS" as a term everywhere (abstract, intro, | part of that, removed "TAPS" as a term everywhere (abstract, intro, | |||
..). | ..). | |||
WG -05: addressed comments from Spencer Dawkins. | WG -05: addressed comments from Spencer Dawkins. | |||
WG -06: Fixed nits. | WG -06: Fixed nits. | |||
WG -07: Addressed Genart comments from Robert Sparks. | ||||
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. 23 change blocks. | ||||
88 lines changed or deleted | 70 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/ |