RFC4782 日本語訳
4782 Quick-Start for TCP and IP. S. Floyd, M. Allman, A. Jain, P.Sarolahti. January 2007. (Format: TXT=214489 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd
Request for Comments: 4782 M. Allman
Category: Experimental ICIR
A. Jain
F5 Networks
P. Sarolahti
Nokia Research Center
January 2007
Network Working Group S. Floyd Request for Comments: 4782 M. Allman Category: Experimental ICIR A. Jain F5 Networks P. Sarolahti Nokia Research Center January 2007
Quick-Start for TCP and IP
Quick-Start for TCP and IP
Status of This Memo
Status of This Memo
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract
Abstract
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled
Floyd, et al. Experimental [Page 1] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 1] RFC 4782 Quick-Start for TCP and IP January 2007
environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
Table of Contents
Table of Contents
1. Introduction ....................................................4
1.1. Conventions and Terminology ................................5
2. Assumptions and General Principles ..............................6
2.1. Overview of Quick-Start ....................................7
3. The Quick-Start Option in IP ...................................10
3.1. The Quick-Start Option for IPv4 ...........................10
3.2. The Quick-Start Option for IPv6 ...........................13
3.3. Processing the Quick-Start Request at Routers .............14
3.3.1. Processing the Report of Approved Rate .............15
3.4. The QS Nonce ..............................................16
4. The Quick-Start Mechanisms in TCP ..............................18
4.1. Sending the Quick-Start Request ...........................19
4.2. The Quick-Start Response Option in the TCP header .........20
4.3. TCP: Sending the Quick-Start Response .....................21
4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22
4.5. TCP: Controlling Acknowledgement Traffic on the
Reverse Path ..............................................24
4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26
4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26
4.7.1. Interactions with Path MTU Discovery ...............26
4.7.2. Quick-Start Request Packets that are
Discarded by Routers or Middleboxes ................27
4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28
4.9. An Example Quick-Start Scenario with TCP ..................29
5. Quick-Start and IPsec AH .......................................30
6. Quick-Start in IP Tunnels and MPLS .............................31
6.1. Simple Tunnels that Are Compatible with Quick-Start .......33
6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33
6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34
6.3. Tunnels That Support Quick-Start ..........................35
6.4. Quick-Start and MPLS ......................................35
7. The Quick-Start Mechanism in Other Transport Protocols .........36
8. Using Quick-Start ..............................................37
8.1. Determining the Rate to Request ...........................37
8.2. Deciding the Permitted Rate Request at a Router ...........37
9. Evaluation of Quick-Start ......................................38
9.1. Benefits of Quick-Start ...................................38
9.2. Costs of Quick-Start ......................................39
9.3. Quick-Start with QoS-Enabled Traffic ......................41
9.4. Protection against Misbehaving Nodes ......................41
9.4.1. Misbehaving Senders ................................41
9.4.2. Receivers Lying about Whether the Request
was Approved .......................................43
1. Introduction ....................................................4 1.1. Conventions and Terminology ................................5 2. Assumptions and General Principles ..............................6 2.1. Overview of Quick-Start ....................................7 3. The Quick-Start Option in IP ...................................10 3.1. The Quick-Start Option for IPv4 ...........................10 3.2. The Quick-Start Option for IPv6 ...........................13 3.3. Processing the Quick-Start Request at Routers .............14 3.3.1. Processing the Report of Approved Rate .............15 3.4. The QS Nonce ..............................................16 4. The Quick-Start Mechanisms in TCP ..............................18 4.1. Sending the Quick-Start Request ...........................19 4.2. The Quick-Start Response Option in the TCP header .........20 4.3. TCP: Sending the Quick-Start Response .....................21 4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22 4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path ..............................................24 4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26 4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26 4.7.1. Interactions with Path MTU Discovery ...............26 4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes ................27 4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28 4.9. An Example Quick-Start Scenario with TCP ..................29 5. Quick-Start and IPsec AH .......................................30 6. Quick-Start in IP Tunnels and MPLS .............................31 6.1. Simple Tunnels that Are Compatible with Quick-Start .......33 6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33 6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34 6.3. Tunnels That Support Quick-Start ..........................35 6.4. Quick-Start and MPLS ......................................35 7. The Quick-Start Mechanism in Other Transport Protocols .........36 8. Using Quick-Start ..............................................37 8.1. Determining the Rate to Request ...........................37 8.2. Deciding the Permitted Rate Request at a Router ...........37 9. Evaluation of Quick-Start ......................................38 9.1. Benefits of Quick-Start ...................................38 9.2. Costs of Quick-Start ......................................39 9.3. Quick-Start with QoS-Enabled Traffic ......................41 9.4. Protection against Misbehaving Nodes ......................41 9.4.1. Misbehaving Senders ................................41 9.4.2. Receivers Lying about Whether the Request was Approved .......................................43
Floyd, et al. Experimental [Page 2] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 2] RFC 4782 Quick-Start for TCP and IP January 2007
9.4.3. Receivers Lying about the Approved Rate ............43
9.4.4. Collusion between Misbehaving Routers ..............44
9.5. Misbehaving Middleboxes and the IP TTL ....................46
9.6. Attacks on Quick-Start ....................................46
9.7. Simulations with Quick-Start ..............................47
10. Implementation and Deployment Issues ..........................47
10.1. Implementation Issues for Sending Quick-Start Requests ...47
10.2. Implementation Issues for Processing Quick-Start
Requests .................................................48
10.3. Possible Deployment Scenarios ............................48
10.4. A Comparison with the Deployment Problems of ECN .........50
11. Security Considerations .......................................50
12. IANA Considerations ...........................................52
12.1. IP Option ................................................52
12.2. TCP Option ...............................................52
13. Conclusions ...................................................53
14. Acknowledgements ..............................................53
Appendix A. Related Work ..........................................54
A.1. Fast Start-Ups without Explicit Information from Routers ..54
A.2. Optimistic Sending without Explicit Information from
Routers ...................................................56
A.3. Fast Start-Ups with Other Information from Routers ........56
A.4. Fast Start-Ups with More Fine-Grained Feedback from
Routers ...................................................57
A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58
Appendix B. Design Decisions ......................................59
B.1. Alternate Mechanisms for the Quick-Start Request:
ICMP and RSVP .............................................59
B.1.1. ICMP ...............................................59
B.1.2. RSVP ...............................................60
B.2. Alternate Encoding Functions ..............................61
B.3. The Quick-Start Request: Packets or Bytes? ................63
B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64
B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65
B.6. Why Not Include More Functionality? .......................66
B.7. Alternate Implementations for a Quick-Start Nonce .........69
B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69
B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69
Appendix C. Quick-Start with DCCP .................................70
Appendix D. Possible Router Algorithm .............................72
Appendix E. Possible Additional Uses for the Quick-Start ..........74
Normative References ..............................................75
Informative References ............................................75
9.4.3. Receivers Lying about the Approved Rate ............43 9.4.4. Collusion between Misbehaving Routers ..............44 9.5. Misbehaving Middleboxes and the IP TTL ....................46 9.6. Attacks on Quick-Start ....................................46 9.7. Simulations with Quick-Start ..............................47 10. Implementation and Deployment Issues ..........................47 10.1. Implementation Issues for Sending Quick-Start Requests ...47 10.2. Implementation Issues for Processing Quick-Start Requests .................................................48 10.3. Possible Deployment Scenarios ............................48 10.4. A Comparison with the Deployment Problems of ECN .........50 11. Security Considerations .......................................50 12. IANA Considerations ...........................................52 12.1. IP Option ................................................52 12.2. TCP Option ...............................................52 13. Conclusions ...................................................53 14. Acknowledgements ..............................................53 Appendix A. Related Work ..........................................54 A.1. Fast Start-Ups without Explicit Information from Routers ..54 A.2. Optimistic Sending without Explicit Information from Routers ...................................................56 A.3. Fast Start-Ups with Other Information from Routers ........56 A.4. Fast Start-Ups with More Fine-Grained Feedback from Routers ...................................................57 A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58 Appendix B. Design Decisions ......................................59 B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP .............................................59 B.1.1. ICMP ...............................................59 B.1.2. RSVP ...............................................60 B.2. Alternate Encoding Functions ..............................61 B.3. The Quick-Start Request: Packets or Bytes? ................63 B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64 B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65 B.6. Why Not Include More Functionality? .......................66 B.7. Alternate Implementations for a Quick-Start Nonce .........69 B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69 B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69 Appendix C. Quick-Start with DCCP .................................70 Appendix D. Possible Router Algorithm .............................72 Appendix E. Possible Additional Uses for the Quick-Start ..........74 Normative References ..............................................75 Informative References ............................................75
Floyd, et al. Experimental [Page 3] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 3] RFC 4782 Quick-Start for TCP and IP January 2007
1. Introduction
1. Introduction
Each connection begins with a question: "What is the appropriate sending rate for the current network path?" The question is not answered explicitly, but each TCP connection determines the sending rate by probing the network path and altering the congestion window (cwnd) based on perceived congestion. Each TCP connection starts with a pre-configured initial congestion window (ICW). Currently, TCP allows an initial window of between one and four segments of maximum segment size (MSS) ([RFC2581], [RFC3390]). The TCP connection then probes the network for available bandwidth using the slow-start procedure ([Jac88], [RFC2581]), doubling cwnd during each congestion-free round-trip time (RTT).
Each connection begins with a question: "What is the appropriate sending rate for the current network path?" The question is not answered explicitly, but each TCP connection determines the sending rate by probing the network path and altering the congestion window (cwnd) based on perceived congestion. Each TCP connection starts with a pre-configured initial congestion window (ICW). Currently, TCP allows an initial window of between one and four segments of maximum segment size (MSS) ([RFC2581], [RFC3390]). The TCP connection then probes the network for available bandwidth using the slow-start procedure ([Jac88], [RFC2581]), doubling cwnd during each congestion-free round-trip time (RTT).
The slow-start algorithm can be time-consuming --- especially over networks with large bandwidth or long delays. It may take a number of RTTs in slow-start before the TCP connection begins to fully use the available bandwidth of the network. For instance, it takes log_2(N) - 2 round-trip times to build cwnd up to N segments, assuming an initial congestion window of 4 segments. This time in slow-start is not a problem for large file transfers, where the slow-start stage is only a fraction of the total transfer time. However, in the case of moderate-sized transfers, the connection might carry out its entire transfer in the slow-start phase, taking many round-trip times, where one or two RTTs might have been sufficient when using the currently available bandwidth along the path.
The slow-start algorithm can be time-consuming --- especially over networks with large bandwidth or long delays. It may take a number of RTTs in slow-start before the TCP connection begins to fully use the available bandwidth of the network. For instance, it takes log_2(N) - 2 round-trip times to build cwnd up to N segments, assuming an initial congestion window of 4 segments. This time in slow-start is not a problem for large file transfers, where the slow-start stage is only a fraction of the total transfer time. However, in the case of moderate-sized transfers, the connection might carry out its entire transfer in the slow-start phase, taking many round-trip times, where one or two RTTs might have been sufficient when using the currently available bandwidth along the path.
A fair amount of work has already been done to address the issue of choosing the initial congestion window for TCP, with RFC 3390 allowing an initial window of up to four segments based on the MSS used by the connection [RFC3390]. Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
A fair amount of work has already been done to address the issue of choosing the initial congestion window for TCP, with RFC 3390 allowing an initial window of up to four segments based on the MSS used by the connection [RFC3390]. Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
In using Quick-Start, a TCP host (say, host A) would indicate its desired sending rate in bytes per second, using a Quick-Start Option in the IP header of a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start Request is not approved. (We note that the `routers' referred to in this document also include the IP-layer processing of the Quick-Start Request at the sender.) In approving a Quick-Start Request, a router does not give preferential treatment to subsequent packets from that connection; the router is only asserting that it is currently underutilized and believes there is sufficient available bandwidth to accommodate the sender's
In using Quick-Start, a TCP host (say, host A) would indicate its desired sending rate in bytes per second, using a Quick-Start Option in the IP header of a TCP packet. Each router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start Request is not approved. (We note that the `routers' referred to in this document also include the IP-layer processing of the Quick-Start Request at the sender.) In approving a Quick-Start Request, a router does not give preferential treatment to subsequent packets from that connection; the router is only asserting that it is currently underutilized and believes there is sufficient available bandwidth to accommodate the sender's
Floyd, et al. Experimental [Page 4] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 4] RFC 4782 Quick-Start for TCP and IP January 2007
requested rate. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick-Start Option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport- level Quick-Start Response in an answering TCP packet.
requested rate. The Quick-Start mechanism can determine if there are routers along the path that do not understand the Quick-Start Option, or have not agreed to the Quick-Start rate request. TCP host B communicates the final rate request to TCP host A in a transport- level Quick-Start Response in an answering TCP packet.
If the Quick-Start Request is approved by all routers along the path, then the TCP host can send at up to the approved rate for a window of data. Subsequent transmissions will be governed by the default TCP congestion control mechanisms of that connection. If the Quick-Start Request is not approved, then the sender would use the default congestion control mechanisms.
If the Quick-Start Request is approved by all routers along the path, then the TCP host can send at up to the approved rate for a window of data. Subsequent transmissions will be governed by the default TCP congestion control mechanisms of that connection. If the Quick-Start Request is not approved, then the sender would use the default congestion control mechanisms.
Quick-Start would not be the first mechanism for explicit communication from routers to transport protocols about sending rates. Explicit Congestion Notification (ECN) gives explicit congestion control feedback from routers to transport protocols, based on the router detecting congestion before buffer overflow [RFC3168]. In contrast, routers would not use Quick-Start to give congestion information, but instead would use Quick-Start as an optional mechanism to give permission to transport protocols to use higher sending rates, based on the ability of all the routers along the path to determine if their respective output links are significantly underutilized.
Quick-Start would not be the first mechanism for explicit communication from routers to transport protocols about sending rates. Explicit Congestion Notification (ECN) gives explicit congestion control feedback from routers to transport protocols, based on the router detecting congestion before buffer overflow [RFC3168]. In contrast, routers would not use Quick-Start to give congestion information, but instead would use Quick-Start as an optional mechanism to give permission to transport protocols to use higher sending rates, based on the ability of all the routers along the path to determine if their respective output links are significantly underutilized.
Section 2 gives an overview of Quick-Start. The formal specifications for Quick-Start are contained in Sections 3, 4, 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 and for IPv6 in Section 3, and is specified for TCP in Section 4. Section 6 consists mostly of a non-normative discussion of interactions of Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware of Quick-Start.
Section 2 gives an overview of Quick-Start. The formal specifications for Quick-Start are contained in Sections 3, 4, 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 and for IPv6 in Section 3, and is specified for TCP in Section 4. Section 6 consists mostly of a non-normative discussion of interactions of Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware of Quick-Start.
The rest of the document is non-normative, as follows. Section 5 shows that Quick-Start is compatible with IPsec AH (Authentication Header). Section 7 gives a non-normative set of guidelines for specifying Quick-Start in other transport protocols, and Section 8 discusses using Quick-Start in transport end-nodes and routers. Section 9 gives an evaluation of the costs and benefits of Quick- Start, and Section 10 discusses implementation and deployment issues. The appendices discuss related work, Quick-Start design decisions, and possible router algorithms.
The rest of the document is non-normative, as follows. Section 5 shows that Quick-Start is compatible with IPsec AH (Authentication Header). Section 7 gives a non-normative set of guidelines for specifying Quick-Start in other transport protocols, and Section 8 discusses using Quick-Start in transport end-nodes and routers. Section 9 gives an evaluation of the costs and benefits of Quick- Start, and Section 10 discusses implementation and deployment issues. The appendices discuss related work, Quick-Start design decisions, and possible router algorithms.
1.1. Conventions and Terminology
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Floyd, et al. Experimental [Page 5] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 5] RFC 4782 Quick-Start for TCP and IP January 2007
2. Assumptions and General Principles
2. Assumptions and General Principles
This section describes the assumptions and general principles behind the design of the Quick-Start mechanism.
This section describes the assumptions and general principles behind the design of the Quick-Start mechanism.
Assumptions:
Assumptions:
* The data transfer in the two directions of a connection traverses
different queues, and possibly even different routers. Thus, any
mechanism for determining the allowed sending rate would have to be
used independently for each direction.
* The data transfer in the two directions of a connection traverses different queues, and possibly even different routers. Thus, any mechanism for determining the allowed sending rate would have to be used independently for each direction.
* The path between the two endpoints is relatively stable, such that
the path used by the Quick-Start Request is generally the same path
used by the Quick-Start packets one round-trip time later.
[ZDPS01] shows this assumption should be generally valid. However,
[RFC3819] discusses a range of Bandwidth on Demand subnets that
could cause the characteristics of the path to change over time.
* The path between the two endpoints is relatively stable, such that the path used by the Quick-Start Request is generally the same path used by the Quick-Start packets one round-trip time later. [ZDPS01] shows this assumption should be generally valid. However, [RFC3819] discusses a range of Bandwidth on Demand subnets that could cause the characteristics of the path to change over time.
* Any new mechanism must be incrementally deployable and might not be
supported by all the routers and/or end-hosts. Thus, any new
mechanism must be able to accommodate non-supporting routers or
end-hosts without disturbing the current Internet semantics. We
note that, while Quick-Start is incrementally deployable in this
sense, a Quick-Start Request cannot be approved for a particular
connection unless both end-nodes and all the routers along the path
have been configured to support Quick-Start.
* Any new mechanism must be incrementally deployable and might not be supported by all the routers and/or end-hosts. Thus, any new mechanism must be able to accommodate non-supporting routers or end-hosts without disturbing the current Internet semantics. We note that, while Quick-Start is incrementally deployable in this sense, a Quick-Start Request cannot be approved for a particular connection unless both end-nodes and all the routers along the path have been configured to support Quick-Start.
General Principles:
General Principles:
* Our underlying premise is that explicit feedback from all the
routers along the path would be required, in the current
architecture, for best-effort connections to use initial windows
significantly larger than those allowed by [RFC3390], in the
absence of other information about the path.
* Our underlying premise is that explicit feedback from all the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path.
* A router should only approve a Quick-Start Request if the output
link is underutilized. Any other approach will result in either
per-flow state at the router, or the possibility of a (possibly
transient) queue at the router.
* A router should only approve a Quick-Start Request if the output link is underutilized. Any other approach will result in either per-flow state at the router, or the possibility of a (possibly transient) queue at the router.
* No per-flow state should be required at the router. Note that,
while per-flow state is not required, we also do not preclude a
router from storing per-flow state for making Quick-Start decisions
or for checking for misbehaving nodes.
* No per-flow state should be required at the router. Note that, while per-flow state is not required, we also do not preclude a router from storing per-flow state for making Quick-Start decisions or for checking for misbehaving nodes.
Floyd, et al. Experimental [Page 6] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 6] RFC 4782 Quick-Start for TCP and IP January 2007
2.1. Overview of Quick-Start
2.1. Overview of Quick-Start
In this section, we give an overview of the use of Quick-Start with TCP to request a higher congestion window. The description in this section is non-normative; the normative description of Quick-Start with IP and TCP follows in Sections 3 and 4. Quick-Start could be used in the middle of a connection, e.g., after an idle or underutilized period, as well as for the initial sending rate; these uses of Quick-Start are discussed later in the document.
In this section, we give an overview of the use of Quick-Start with TCP to request a higher congestion window. The description in this section is non-normative; the normative description of Quick-Start with IP and TCP follows in Sections 3 and 4. Quick-Start could be used in the middle of a connection, e.g., after an idle or underutilized period, as well as for the initial sending rate; these uses of Quick-Start are discussed later in the document.
Quick-Start requires end-points and routers to work together, with end-points requesting a higher sending rate in the Quick-Start (QS) option in IP, and routers along the path approving, modifying, discarding, or ignoring (and therefore disallowing) the Quick-Start Request. The receiver uses reliable, transport-level mechanisms to inform the sender of the status of the Quick-Start Request. For example, when TCP is used, the TCP receiver sends feedback to the sender using a Quick-Start Response option in the TCP header. In addition, Quick-Start assumes a unicast, congestion-controlled transport protocol; we do not consider the use of Quick-Start for multicast traffic.
Quick-Start requires end-points and routers to work together, with end-points requesting a higher sending rate in the Quick-Start (QS) option in IP, and routers along the path approving, modifying, discarding, or ignoring (and therefore disallowing) the Quick-Start Request. The receiver uses reliable, transport-level mechanisms to inform the sender of the status of the Quick-Start Request. For example, when TCP is used, the TCP receiver sends feedback to the sender using a Quick-Start Response option in the TCP header. In addition, Quick-Start assumes a unicast, congestion-controlled transport protocol; we do not consider the use of Quick-Start for multicast traffic.
When sent as a request, the Quick-Start Option includes a request for a sending rate in bits per second, and a Quick-Start Time to Live (QS TTL) to be decremented by every router along the path that understands the option and approves the request. The Quick-Start TTL is initialized by the sender to a random value. The transport receiver returns the rate, information about the TTL, and the Quick- Start Nonce to the sender using transport-level mechanisms; for TCP, the receiver sends this information in the Quick-Start Response in the TCP header. In particular, the receiver computes the difference between the Quick-Start TTL and the IP TTL (the TTL in the IP header) of the Quick-Start Request packet, and returns this in the Quick- Start Response. The sender uses the TTL difference to determine if all the routers along the path decremented the Quick-Start TTL, approving the Quick-Start Request.
When sent as a request, the Quick-Start Option includes a request for a sending rate in bits per second, and a Quick-Start Time to Live (QS TTL) to be decremented by every router along the path that understands the option and approves the request. The Quick-Start TTL is initialized by the sender to a random value. The transport receiver returns the rate, information about the TTL, and the Quick- Start Nonce to the sender using transport-level mechanisms; for TCP, the receiver sends this information in the Quick-Start Response in the TCP header. In particular, the receiver computes the difference between the Quick-Start TTL and the IP TTL (the TTL in the IP header) of the Quick-Start Request packet, and returns this in the Quick- Start Response. The sender uses the TTL difference to determine if all the routers along the path decremented the Quick-Start TTL, approving the Quick-Start Request.
If the request is approved by all the routers along the path, then the TCP sender combines this allowed rate with the measurement of the round-trip time, and ends up with an allowed TCP congestion window. This window is sent rate-paced over the next round-trip time, or until an ACK packet is received.
If the request is approved by all the routers along the path, then the TCP sender combines this allowed rate with the measurement of the round-trip time, and ends up with an allowed TCP congestion window. This window is sent rate-paced over the next round-trip time, or until an ACK packet is received.
Figure 1 shows a successful use of Quick-Start, with the sender's IP layer and both routers along the path approving the Quick-Start Request, and the TCP receiver using the Quick-Start Response to return information to the TCP sender. In this example, Quick-Start is used by TCP to establish the initial congestion window.
Figure 1 shows a successful use of Quick-Start, with the sender's IP layer and both routers along the path approving the Quick-Start Request, and the TCP receiver using the Quick-Start Response to return information to the TCP sender. In this example, Quick-Start is used by TCP to establish the initial congestion window.
Floyd, et al. Experimental [Page 7] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 7] RFC 4782 Quick-Start for TCP and IP January 2007
Sender Router 1 Router 2 Receiver ------ -------- -------- -------- | <IP TTL: 63> | <QS TTL: 91> | <TTL Diff: 28> | Quick-Start Request | in SYN or SYN/ACK. | IP: Decrement QS TTL | to approve request --> | | Decrement | QS TTL | to approve | request --> | | Decrement | QS TTL | to approve | request --> | | <IP TTL: 60> | <QS TTL: 88> | <TTL Diff: 28> | Return Quick-Start | info to sender in | Quick-Start Response | <-- in TCP ACK packet. | | <TTL Diff: 28> | Quick-Start approved, | translate to cwnd. | Report Approved Rate. V Send cwnd paced over one RTT. -->
Sender Router 1 Router 2 Receiver ------ -------- -------- -------- | <IP TTL: 63> | <QS TTL: 91> | <TTL Diff: 28> | Quick-Start Request | in SYN or SYN/ACK. | IP: Decrement QS TTL | to approve request --> | | Decrement | QS TTL | to approve | request --> | | Decrement | QS TTL | to approve | request --> | | <IP TTL: 60> | <QS TTL: 88> | <TTL Diff: 28> | Return Quick-Start | info to sender in | Quick-Start Response | <-- in TCP ACK packet. | | <TTL Diff: 28> | Quick-Start approved, | translate to cwnd. | Report Approved Rate. V Send cwnd paced over one RTT. -->
Figure 1: A Successful Quick-Start Request.
Figure 1: A Successful Quick-Start Request.
Figure 2 shows an unsuccessful use of Quick-Start, with one of the routers along the path not approving the Quick-Start Request. If the Quick-Start Request is not approved, then the sender uses the default congestion control mechanisms for that transport protocol, including the default initial congestion window, response to idle periods, etc.
Figure 2 shows an unsuccessful use of Quick-Start, with one of the routers along the path not approving the Quick-Start Request. If the Quick-Start Request is not approved, then the sender uses the default congestion control mechanisms for that transport protocol, including the default initial congestion window, response to idle periods, etc.
Floyd, et al. Experimental [Page 8] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 8] RFC 4782 Quick-Start for TCP and IP January 2007
Sender Router 1 Router 2 Receiver ------ -------- -------- -------- | <IP TTL: 63> | <QS TTL: 91> | <TTL Diff: 28> | Quick-Start Request | in SYN or SYN/ACK. | IP: Decrement QS TTL | to approve request --> | | Decrement | QS TTL | to approve | request --> | | Forward packet | without modifying | Quick-Start Option. --> | | <IP TTL: 60> | <QS TTL: 89> | <TTL Diff: 29> | Return Quick-Start | info to sender in | Quick-Start Response | <-- in TCP ACK packet. | | <TTL Diff: 29> | Quick-Start not approved. | Report approved rate. V Use default initial cwnd. -->
Sender Router 1 Router 2 Receiver ------ -------- -------- -------- | <IP TTL: 63> | <QS TTL: 91> | <TTL Diff: 28> | Quick-Start Request | in SYN or SYN/ACK. | IP: Decrement QS TTL | to approve request --> | | Decrement | QS TTL | to approve | request --> | | Forward packet | without modifying | Quick-Start Option. --> | | <IP TTL: 60> | <QS TTL: 89> | <TTL Diff: 29> | Return Quick-Start | info to sender in | Quick-Start Response | <-- in TCP ACK packet. | | <TTL Diff: 29> | Quick-Start not approved. | Report approved rate. V Use default initial cwnd. -->
Figure 2: An Unsuccessful Quick-Start Request.
Figure 2: An Unsuccessful Quick-Start Request.
Floyd, et al. Experimental [Page 9] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 9] RFC 4782 Quick-Start for TCP and IP January 2007
3. The Quick-Start Option in IP
3. The Quick-Start Option in IP
3.1. The Quick-Start Option for IPv4
3.1. The Quick-Start Option for IPv4
The Quick-Start Request for IPv4 is defined as follows:
The Quick-Start Request for IPv4 is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | QS TTL |
| | | 0000 |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option | Length=8 | Func. | Rate | QS TTL | | | | 0000 |Request| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QS Nonce | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Quick-Start Option for IPv4.
A Quick-Start Request.
Figure 3: The Quick-Start Option for IPv4. A Quick-Start Request.
The first byte contains the option field, which includes the one-bit copy flag, the 2-bit class field, and the 5-bit option number.
The first byte contains the option field, which includes the one-bit copy flag, the 2-bit class field, and the 5-bit option number.
The second byte contains the length field, indicating an option length of eight bytes.
8バイトのオプションの長さを示して、2番目のバイトは長さの分野を含んでいます。
The third byte includes a four-bit Function field. If the Function field is set to "0000", then the Quick-Start Option is a Rate Request. In this case, the second half of the third byte is a four- bit Rate Request field.
3番目のバイトは4ビットのFunction分野を含んでいます。 Function分野が「そして、クィックスタートオプションは何0インチも、レート要求です」に設定されるなら。 この場合、3番目のバイトの後半はRate Requestがさばく4ビットです。
For a Rate Request, the fourth byte contains the Quick-Start TTL (QS TTL) field. The sender MUST set the QS TTL field to a random value. Routers that approve the Quick-Start Request decrement the QS TTL (mod 256) by the same amount that they decrement the IP TTL. (As elsewhere in this document, we use the term `router' imprecisely to also include the Quick-Start functionality at the IP layer at the sender.) The QS TTL is used by the sender to detect if all the routers along the path understood and approved the Quick-Start option.
Rate Requestに関しては、4番目のバイトはクィック-スタートTTL(QS TTL)分野を含んでいます。 送付者は無作為の値にQS TTL分野を設定しなければなりません。 同じ量に従って、クィック-スタートRequestを承認するルータがQS TTL(モッズ風の256)を減少させます。それらはIP TTLを減少させます。 (私たちがまた、送付者におけるIP層にクィック-スタートの機能性を含むのにこのドキュメントのほかの場所で不正確に'ルータ'という用語を使用するとき。) QS TTLは、経路に沿ったすべてのルータがクィック-スタートオプションを理解して、承認したかどうか検出するのに送付者によって使用されます。
For a Rate Request, the transport sender MUST calculate and store the TTL Diff, the difference between the IP TTL value, and the QS TTL value in the Quick-Start Request packet, as follows:
Rate Requestに関しては、輸送送付者は、クィック-スタートRequestパケットにTTL Diff、IP TTL値と、QS TTL値の違いを計算して、格納しなければなりません、以下の通りです:
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
TTL Diff=(IP TTL--QS TTL)のモッズ風の256(1)
Floyd, et al. Experimental [Page 10] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[10ページ]RFC4782クィックスタートとIP2007年1月
For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed in Section 3.4, and a two-bit Reserved field. The sender SHOULD set the reserved field to zero, and routers and receivers SHOULD ignore the reserved field. The sender SHOULD set the 30-bit QS Nonce to a random value.
Rate Requestに関しては、バイト5-8はセクション3.4で議論した、30ビットのQS Nonce、および安っぽいReserved分野を含んでいます。 送付者SHOULDは予約された分野をゼロに設定します、そして、ルータと受信機SHOULDは予約された分野を無視します。 送付者SHOULDは30ビットのQS Nonceを無作為の値に設定します。
The sender initializes the Rate Request to the desired sending rate, including an estimate of the transport and IP header overhead. The encoding function for the Rate Request sets the request rate to K*2^N bps (bits per second), for N the value in the Rate Request field, and for K set to 40,000. For N=0, the rate request would be set to zero, regardless of the encoding function. This is illustrated in Table 1 below. For the four-bit Rate Request field, the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered for the Rate Request are given in Appendix B.2.
送付者は必要な送付レートにRate Requestを初期化します、輸送とIPヘッダーオーバーヘッドの見積りを含んでいて。 Rate Requestが要求を設定するので、コード化機能は、Rate Request分野、および4万に設定されたKのためにNのための2^Nビーピーエス(bps)が値であるとK*に評定します。 N=0において、レート要求はコード化機能にかかわらずゼロに設定されるでしょう。 これは以下のTable1で例証されます。 4ビットのRate Request分野のために、要求範囲は1.3Gbpsへの80Kbpsからのものです。 Appendix B.2でRate Requestのために考えられた交互のencodingsを与えます。
N Rate Request (in Kbps)
--- ----------------------
0 0
1 80
2 160
3 320
4 640
5 1,280
6 2,560
7 5,120
8 10,240
9 20,480
10 40,960
11 81,920
12 163,840
13 327,680
14 655,360
15 1,310,720
Nレート要求(キロビット毎秒における)--- ---------------------- 0 0 1 80 2 160 3 320 4 640 5 1,280 6 2,560 7 5,120 8 10,240 9 20,480 10 40,960 11 81,920 12 163,840 13 327,680 14 655,360 15 1,310,720
Table 1: Mapping from Rate Request Field to Rate Request in Kbps.
テーブル1: キロビット毎秒でレート要求分野からレート要求まで写像します。
Routers can approve the Quick-Start Request for a lower rate by decreasing the Rate Request in the Quick-Start Request. Section 4.2 discusses the Quick-Start Response from the TCP receiver to the TCP sender, and Section 4.4 discusses the TCP sender's mechanism for determining if a Quick-Start Request has been approved.
ルータは、低料金のためにクィック-スタートRequestでRate Requestを減少させることによって、クィック-スタートRequestを承認できます。 セクション4.2はTCP受信機からTCP送付者までクィック-スタートResponseについて論じます、そして、セクション4.4はクィック-スタートRequestが承認されたかどうか決定するためにTCP送付者のメカニズムについて議論します。
Floyd, et al. Experimental [Page 11] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[11ページ]RFC4782クィックスタートとIP2007年1月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | Not Used |
| | | 1000 | Report| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| 長さ=8| Func。 | レート| 使用されません。| | | | 1000 | レポート| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QS一回だけ| R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Quick-Start Option for IPv4.
Report of Approved Rate.
図4: IPv4のためのクィックスタートオプション。 承認されたレートのレポート。
If the Function field in the third byte of the Quick-Start Option is set to "1000", then the Quick-Start Option is a Report of Approved Rate. In this case, the second four bits in the third byte are the Rate Report field, formatted exactly as in the Rate Request field in a Rate Request. For a Report of Approved Rate, the fourth byte of the Quick-Start Option is not used. Bytes 5-8 contain a 30-bit QS Nonce and a 2-bit Reserved field.
クィック-スタートOptionの3番目のバイトにおけるFunction分野が「1000」に設定されるなら、クィックスタートオプションは承認されたレートのレポートです。 この場合、3番目のバイトにおける2番目の4ビットはちょうどRate RequestのRate Request分野のようにフォーマットされたRate Report分野です。 Approved RateのReportに関しては、クィック-スタートOptionの4番目のバイトは使用されていません。 バイト5-8は30ビットのQS Nonceと2ビットのReserved分野を含んでいます。
After an approved Rate Request, the sender MUST report the Approved Rate, using a Quick-Start Option configured as a Report of Approved Rate with the Rate Report field set to the approved rate, and the QS Nonce set to the QS Nonce sent in the Quick-Start Request. The packet containing the Report of Approved Rate MUST be either a control packet sent before the first Quick-Start data packet, or a Quick-Start Option in the first data packet itself. The Report of Approved Rate does not have to be sent reliably; for example, if the approved rate is reported in a separate control packet, the sender does not necessarily know if the control packet has been dropped in the network. If the packet containing the Quick-Start Request is acknowledged, but the acknowledgement packet does not contain a Quick-Start Response, then the sender MUST assume that the Quick- Start Request was denied, and set a Report of Approved Rate with a rate of zero. Routers may choose to ignore the Report of Approved Rate, or to use the Report of Approved Rate but ignore the QS Nonce. Alternately, some routers that use the Report of Approved Rate may choose to match the QS Nonce, masked by the approved rate, with the QS Nonce seen in the original request.
承認されたRate Requestの後に、送付者はApproved Rateを報告しなければなりません、Rate Report分野があるApproved RateのReportが承認されたレートにセットして、QS Nonceに用意ができているQS Nonceがクィック-スタートRequestを送ったので構成されたクィック-スタートOptionを使用して。 Approved RateのReportを含むパケットは、最初のクィック-スタートデータ・パケットの前に送られたコントロールパケットか最初のデータ・パケット自体のクィック-スタートOptionのどちらかであるに違いありません。 Approved RateのReportを確かに送る必要はありません。 例えば、承認されたレートが別々のコントロールパケットで報告されるなら、送付者は、コントロールパケットがネットワークで落とされたかどうかを必ず知っているというわけではありません。 クィック-スタートRequestを含むパケットが承認されますが、確認応答パケットがクィック-スタートResponseを含んでいないなら、送付者は、クィックスタートRequestが否定されて、ゼロのレートでApproved RateのReportを設定すると仮定しなければなりません。 ルータは、Approved RateのReportを無視するか、Approved RateのReportを使用しますが、またはQS Nonceを無視するのを選ぶかもしれません。 交互に、Approved RateのReportを使用するいくつかのルータが、承認されたレートで隠されるQS Nonceをオリジナルの要求で見られるQS Nonceに合わせるのを選ぶかもしれません。
If the Rate Request is denied, the sender MUST send a Report of Approved Rate with the Rate Report field set to zero.
Rate Requestが否定されるなら、送付者はRate Report分野セットがあるApproved RateのReportをゼロに送らなければなりません。
We note that, unlike a Quick-Start Request sent at the beginning of a connection, when a Quick-Start Request is sent in the middle of a connection, the connection could already have an established congestion window or sending rate. The Rate Request is the requested total rate for the connection, including the current rate of the
私たちは、接続が既にクィック-スタートRequestが接続の途中で送られる接続の始めに送られたクィック-スタートRequestと異なって確立した混雑ウィンドウか送付レートを持つことができたことに注意します。 電流を含んでいるのは、Rate Requestが接続の要求された総速度であると評価します。
Floyd, et al. Experimental [Page 12] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[12ページ]RFC4782クィックスタートとIP2007年1月
connection; the Rate Request is *not* a request for an additional sending rate over and above the current sending rate. If the Rate Request is denied, or lowered to a value below the connection's current sending rate, then the sender ignores the request, and reverts to the default congestion control mechanisms of the transport protocol.
接続。 Rate Requestは追加送付を求める要求が速度の上と現在の送付速度より上で評定する*ではなく、*です。 Rate Requestが値に否定されるか、または接続の現在の送付レートより下であるまで下ろされるなら、送付者は、要求を無視して、トランスポート・プロトコルのデフォルト混雑制御機構に先祖帰りをします。
The use of the Quick-Start Option does not require the additional use of the Router Alert Option [RFC2113].
クィック-スタートOptionの使用はRouter Alert Option[RFC2113]の追加使用を必要としません。
We note that in IPv4, a change in IP options at routers requires recalculating the IP header checksum.
私たちは、IPv4では、ルータにおけるIPオプションにおける変化が、IPヘッダーチェックサムについて再計算するのを必要とすることに注意します。
3.2. The Quick-Start Option for IPv6
3.2. IPv6のためのクィックスタートオプション
The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options extension header that is processed at every network node along the communication path [RFC2460]. The option format following the generic Hop-by-Hop Options header is identical to the IPv4 format, with the exception that the Length field should exclude the common type and length fields in the option format and be set to 6 bytes instead of 8 bytes.
IPv6のためのクィック-スタートOptionは通信路[RFC2460]に沿ってあらゆるネットワーク・ノードで処理されるホップによるHop Options拡張ヘッダーに置かれます。 一般的なホップによるHop Optionsヘッダーに続くオプション形式はIPv4形式と同じです、Length分野がオプション形式で普通形と長さの分野を遮断して、そう8バイトの代わりに6バイトにセットした例外をあるべきである状態で。
For a Quick-Start Request, the transport receiver compares the Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL Diff. (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff MUST be calculated and stored as follows:
クィック-スタートRequestに関しては、輸送受信機は、TTL Diffについて計算するためにクィック-スタートTTLをIPv6 Hop Limit分野と比べます。 (IPv6のHop LimitはIPv4のTTLの同等物です。) 以下の通りすなわち、TTL Diffを計算されて、格納しなければなりません:
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
TTL Diff=(IPv6 Hop Limit--QS TTL)のモッズ風の256(2)
Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does not require checksum re-calculation, because the IPv6 header does not have a checksum field, and modifying the Quick-Start Request in the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo- header checksum used in upper-layer checksum calculations.
IPv4と異なって、クィック-スタートIPv6 Optionを変更するか、または削除するのがチェックサム再計算を必要としません、IPv6ヘッダーにはチェックサム分野がなくて、またホップによるIPv6 Hopオプションヘッダーでクィック-スタートRequestを変更する場合チェックサムが上側の層のチェックサム計算に使用したIPv6疑似ヘッダーが影響されないので。
Appendix A of RFC 2460 requires that all packets with the same flow label must be originated with the same hop-by-hop header contents, which would be incompatible with Quick-Start. However, a later IPv6 flow label specification [RFC3697] updates the use of flow labels in IPv6 and removes this restriction. Therefore, Quick-Start is compatible with the current IPv6 specifications.
RFC2460の付録Aは、ホップごとのクィック-始めと両立しないだろうというのと同じヘッダーコンテンツで同じ流れラベルがあるすべてのパケットを溯源しなければならないのを必要とします。 しかしながら、後のIPv6流れラベル仕様[RFC3697]は、IPv6における流れラベルの使用をアップデートして、この制限を取り除きます。 したがって、クィック-始めは現在のIPv6仕様と互換性があります。
Floyd, et al. Experimental [Page 13] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[13ページ]RFC4782クィックスタートとIP2007年1月
3.3. Processing the Quick-Start Request at Routers
3.3. ルータでクィックスタート要求を処理します。
The Quick-Start Request does not report the current sending rate of the connection sending the request; in the default case of a router (or IP-layer implementation at an end-node) that does not maintain per-flow state, a router makes the conservative assumption that the flow's current sending rate is zero. Each participating router can either terminate or approve the Quick-Start Request. A router MUST only approve a Quick-Start Request if the output link is underutilized, and if the router judges that the output link will continue to be underutilized if this and earlier approved requests are used by the senders. Otherwise, the router reduces or terminates the Quick-Start Request.
クィック-スタートRequestは要求を送る接続の現在の送付速度を報告しません。 1流れあたりの状態を維持しないルータ(または、IP-層の実現の終わりなノード)の不履行格では、ルータは流れの現在の送付レートがゼロであるという保守的な仮定をします。 それぞれの参加ルータは、クィック-スタートRequestを終えるか、または承認できます。 出力リンクがunderutilizedされて、ルータが、これと以前の承認された要求が送付者によって使用されると出力リンクが、underutilizedされ続けると判断するなら、ルータはクィック-スタートRequestを承認するだけでよいです。 さもなければ、ルータは、クィック-スタートRequestを減少するか、または終えます。
While the paragraph above defines the *semantics* of approving a Quick-Start Request, this document does not specify the specific algorithms to be used by routers in processing Quick-Start Requests or Reports. This is similar to RFC 3168, which specifics the semantics of the ECN codepoints in the IP header, but does not specify specific algorithms for routers to use in deciding when to drop or mark packets before buffer overflow.
上のパラグラフがクィック-スタートRequestを承認する*意味論*を定義している間、このドキュメントは、処理クィック-スタートのRequestsかReportsでルータによって使用されるために特定のアルゴリズムを指定しません。 これはRFC3168と同様です。ルータがバッファオーバーフローの前のいつ低下するかを決めるか、マークパケットで使用するように、電子証券取引ネットワークの意味論は、その詳細にIPヘッダーでcodepointsしますが、特定のアルゴリズムを指定しません。
A router that wishes to terminate the Quick-Start Request SHOULD either delete the Quick-Start Request from the IP header or zero the QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start Request saves resources because downstream routers will have no option to process, but zeroing the Rate Request field may be more efficient for routers to implement. As suggested in [B05], future additions to Quick-Start could define error codes for routers to insert into the QS Nonce field to report back to the sender the reason that the Quick-Start Request was denied, e.g., that the router is denying all Quick-Start Requests at this time, or that this router, as a matter of policy, does not grant Quick-Start requests. A router that doesn't understand the Quick-Start Option will simply forward the packet with the Quick-Start Request unchanged (ensuring that the TTL Diff will not match and Quick-Start will not be used).
Request SHOULDがクィック-始めを終えるために、IPヘッダーからクィック-スタートRequestを削除するか、またはQS TTLのゼロに合っていることを願っているルータ、QS Nonce、およびRate Request分野。 クィック-スタートRequestを削除すると、川下のルータには処理しないオプションが全くあるので、リソースは保存されますが、ルータが実行するように、Rate Request分野のゼロを合わせるのは、より効率的であるかもしれません。 [B05]ではクィック-始めへの今後の追加がルータがクィック-スタートRequestが否定されて、例えば、ルータがこのときすべてのクィック-スタートRequestsを否定している理由の送付者に報告を持ちかえるためにQS Nonce分野に挿入するエラーコードを定義するかもしれないか、またはこのルータが政策の問題としてクィック-スタート要求を承諾しないのを示すので。 クィック-スタートRequestが変わりがない状態でクィック-スタートOptionを理解していないルータは単にパケットを進めるでしょう(TTL Diffが合わないのを確実にして、クィック-始めは使用されないでしょう)。
If the participating router has decided to approve the Quick-Start Request, it does the following:
参加ルータが、クィック-スタートRequestを承認すると決めたなら、以下をします:
* The router MUST decrement the QS TTL by the amount the IP TTL is
decremented (usually one).
* 量に従って、ルータはQS TTLを減少させなければなりません。IP TTLは減少します(通常1)。
* If the router is only willing to approve a Rate Request less than
that in the Quick-Start Request, then the router replaces the Rate
Request with a smaller value. The router MUST NOT increase the
Rate Request in the Quick-Start Request. If the router decreases
* ルータが、クィック-スタートRequestにおけるそれほどRate Requestを承認しないでも構わないと思っているだけであるなら、ルータはRate Requestをより小さい値に取り替えます。 ルータはクィック-スタートRequestでRate Requestを増加させてはいけません。 ルータが減少するなら
Floyd, et al. Experimental [Page 14] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[14ページ]RFC4782クィックスタートとIP2007年1月
the Rate Request, the router MUST also modify the QS Nonce, as
described in Section 3.4.
Rate Request、ルータは変更しなければなりません、また、セクション3.4で説明されるようにQS Nonceを変更してください。
* In IPv4, the router MUST update the IP header checksum.
* IPv4では、ルータはIPヘッダーチェックサムをアップデートしなければなりません。
If the router approves the Quick-Start Request, this approval SHOULD be taken into account in the router's decision to accept or reject subsequent Quick-Start Requests (e.g., using a variable that tracks the recent aggregate of accepted Quick-Start Requests). This consideration of earlier approved Quick-Start Requests is necessary to ensure that the router only approves a Quick-Start Request when the router judges that the output link will remain underutilized if this and earlier Quick-Start Requests are used by the senders.
ルータがその後のクィック-スタートRequests(例えば、受け入れられたクィック-スタートRequestsの最近の集合を追跡する変数を使用する)を受け入れるか、または拒絶するというルータの決定でアカウントに連れていった状態でクィック-スタートRequest、この承認のSHOULDを承認するなら。 以前の承認されたクィック-スタートRequestsのこの考慮が、これと以前のクィック-スタートRequestsが送付者によって使用されるならルータ裁判官が出力リンクが残っているunderutilizedしたときだけ、ルータがクィック-スタートRequestを承認するのを保証するのに必要です。
In addition, the approval of a Quick-Start Request SHOULD NOT be used by the router to affect the treatment of the data packets that arrive from this connection in the next few round-trip times. That is, the approval by the router of a Quick-Start Request does not give differential treatment for Quick-Start data packets at that router; it is only a statement from the router that the router believes that the subsequent Quick-Start data packets from this connection will not change the current underutilized state of the router.
さらに、aの承認はRequest SHOULDをクィックと同じくらい始動します。ルータによって使用されて、この接続から次の往復の数回に到着するデータ・パケットの処理に影響することがなくなってください。 すなわち、クィック-スタートRequestのルータによる承認はそのルータでクィック-スタートデータ・パケットに関する差別待遇を与えません。 それはルータからのルータが、この接続からのその後のクィック-スタートデータ・パケットがルータの現在のunderutilized状態を変えないと信じているという声明にすぎません。
A non-participating router forwards the Quick-Start Request unchanged, without decrementing the QS TTL. The non-participating router still decrements the TTL field in the IP header, as is required for all routers [RFC1812]. As a result, the sender will be able to detect that the Quick-Start Request had not been understood or approved by all of the routers along the path.
非参加ルータはQS TTLを減少させないで変わりのないクィック-スタートRequestを進めます。 非参加ルータはすべてのルータ[RFC1812]に必要であるようにIPヘッダーのTTL分野をまだ減少させています。 結果、送付者がそれを検出できるので、クィック-スタートRequestは経路に沿ってすべてによってルータを、理解されていなかったか、または承認されていませんでした。
A router that uses multipath routing for packets within a single connection MUST NOT approve a Quick-Start Request. This is discussed in more detail in Section 9.2.
パケットに単独結合の中で多重通路ルーティングを使用するルータはクィック-スタートRequestを承認してはいけません。 さらに詳細にセクション9.2でこれについて議論します。
3.3.1. Processing the Report of Approved Rate
3.3.1. 承認されたレートのレポートを処理します。
If the Quick-Start Option has the Function field set to "1000", then this is a Report of Approved Rate, rather than a Rate Request. The router MAY ignore such an option, and, in any case, it MUST NOT modify the contents of the option for a Report of Approved Rate. However, the router MAY use the Approved Rate report to check that the sender is not lying about the approved rate. If the reported Approved Rate is higher than the rate that the router actually approved for this connection in the previous round-trip time, then the router may implement some policy for cheaters. For instance, the router MAY decide to deny future Quick-Start Requests from this sender, including, if desired, deleting Quick-Start Requests from future packets from this sender. Section 9.4.1 discusses misbehaving
クィック-スタートOptionが「1000」にFunction分野を設定させるなら、これはレート要求よりむしろ承認されたレートのレポートです。 ルータはそのようなオプションを無視するかもしれません、そして、どのような場合でも、それはApproved RateのReportのためにオプションのコンテンツを変更してはいけません。 しかしながら、ルータは、送付者が承認されたレートに関して嘘をついていないのをチェックするのにApproved Rateレポートを使用するかもしれません。 報告されたApproved Rateがルータがこの接続のために実際に前の往復の時間で承認したレートより高いなら、ルータは詐欺師のためにいくつかの政策を実施するかもしれません。 例えば、ルータは、この送付者から将来のクィック-スタートRequestsを否定すると決めるかもしれません、含んでいます、望まれているなら、将来のパケットからこの送付者からクィック-スタートRequestsを削除して。 セクション9.4.1は、ふらちな事をするのを議論します。
Floyd, et al. Experimental [Page 15] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[15ページ]RFC4782クィックスタートとIP2007年1月
senders in more detail. From the Report of Approved Rate, the router can also learn if some of the downstream routers have approved the Quick-Start Request for a smaller rate or denied the use of Quick- Start, and adjust its bandwidth allocations accordingly.
その他の詳細の送付者。 Approved RateのReportから、ルータは、また、川下のルータのいくつかが、よりわずかなレートのためにクィック-スタートRequestを承認したか、またはクィック始めの使用を否定したかを学んで、帯域幅配分をそれに従って、調整できます。
3.4. The QS Nonce
3.4. QS一回だけ
The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. This is particularly important if the receiver knows the original value of the Rate Request (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, when the received Rate Request was, in fact, less than K.
QS Nonceは容認されたRate Requestの値に関してある受信機に対する何らかの保護をクィック-スタート送付者に与えます。 受信機がRate Requestの元の値を知っているなら(例えば、受信機には、いつ、送付者はいつも同じ値を要求して、その送付者とのコミュニケーションの長い歴史がありますか)、これは特に重要です。 QS Nonceがなければ、何も受信機がKのRate Requestの送付者に報告を持ちかえるのを防ぐものがありません、容認されたRate RequestがK事実上以下であったときに。
Table 2 gives the format for the 30-bit QS Nonce.
テーブル2は30ビットのQS Nonceのために書式を与えます。
Bits Purpose --------- ------------------ Bits 0-1: Rate 15 -> Rate 14 Bits 2-3: Rate 14 -> Rate 13 Bits 4-5: Rate 13 -> Rate 12 Bits 6-7: Rate 12 -> Rate 11 Bits 8-9: Rate 11 -> Rate 10 Bits 10-11: Rate 10 -> Rate 9 Bits 12-13: Rate 9 -> Rate 8 Bits 14-15: Rate 8 -> Rate 7 Bits 16-17: Rate 7 -> Rate 6 Bits 18-19: Rate 6 -> Rate 5 Bits 20-21: Rate 5 -> Rate 4 Bits 22-23: Rate 4 -> Rate 3 Bits 24-25: Rate 3 -> Rate 2 Bits 26-27: Rate 2 -> Rate 1 Bits 28-29: Rate 1 -> Rate 0
ビット目的--------- ------------------ ビット0-1: 15->レート14がビット2-3であると評定してください: 14->レート13がビット4-5であると評定してください: 13->レート12がビット6-7であると評定してください: 12->レート11がビット8-9であると評定してください: 11->レート10がビット10-11であると評定してください: 10->レート9がビット12-13であると評定してください: 9->レート8がビット14-15であると評定してください: 8->レート7がビット16-17であると評定してください: 7->レート6がビット18-19であると評定してください: 6->レート5がビット20-21であると評定してください: 5->レート4がビット22-23であると評定してください: 4->レート3がビット24-25であると評定してください: 3->レート2がビット26-27であると評定してください: 2->レート1がビット28-29であると評定してください: レート1->レート0
Table 2: The QS Nonce.
テーブル2: QS一回だけ。
The transport sender MUST initialize the QS Nonce to a random value. If the router reduces the Rate Request from rate K to rate K-1, then the router MUST set the field in the QS Nonce for "Rate K -> Rate K-1" to a new random value. Similarly, if the router reduces the Rate Request by N steps, the router MUST set the 2N bits in the relevant fields in the QS Nonce to a new random value. The receiver MUST report the QS Nonce back to the sender.
輸送送付者は無作為の値にQS Nonceを初期化しなければなりません。 ルータはRate RequestをレートKからレートK-1まで減少させます、ルータがQS Nonceの分野を設定しなければならないその時、「レートK->が評価する、K-1インチ、新しい無作為の値、」 同様に、ルータがNステップでRate Requestを減少させるなら、ルータは新しい無作為の値へのQS Nonceの関連分野に2Nビットをはめ込まなければなりません。 受信機は送付者にQS Nonceの報告を持ちかえらなければなりません。
Floyd, et al. Experimental [Page 16] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[16ページ]RFC4782クィックスタートとIP2007年1月
If the Rate Request was not decremented in the network, then the QS Nonce should have its original value. Similarly, if the Rate Request was decremented by N steps in the network, and the receiver reports back a Rate Request of K, then the last 2K bits of the QS Nonce should have their original value.
Rate Requestがネットワークで減少しないなら、QS Nonceには、元の値があるでしょうに。 同様に、Rate RequestがネットワークにおけるNステップで減少して、受信機レポートがKのRate Requestを支持するなら、QS Nonceの最後の2Kのビットには、それらの元の値があるはずです。
With the QS Nonce, the receiver has a 1/4 chance of cheating about each step change in the rate request. Thus, if the rate request is reduced by two steps in the network, the receiver has a 1/16 chance of successfully reporting that the original request was approved, as this requires reporting the original value for the QS nonce. Similarly, if the rate request is reduced many steps in the network, and the receiver receives a QS Option with a rate request of K, the receiver has a 1/16 chance of guessing the original values for the fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> Rate K". Thus, the receiver has a 1/16 chance of successfully lying and saying that the received rate request was K+2 instead of K.
QS Nonceがあるので、受信機で、各ステップの周りで不正行為をするという1/4機会はレート要求で変化します。 したがって、受信機には、レート要求がネットワークにおける2ステップで減らされるなら、オリジナルの要求が承認されたと首尾よく報告するという1/16機会があります、これが、QS一回だけのために元の値を報告するのを必要とするとき。 同様に、レート要求がネットワークで多くのステップで減らされて、受信機がKのレート要求でQS Optionを受けるなら、受信機には、「レートK+2->レートK+1」と「レートK+1->レートK」のためにQS一回だけの分野に元の値を推測するという1/16機会があります。 したがって、受信機には、首尾よく横たわっていて、受信されたレート要求がKの代わりにK+2であったと言うという1/16機会があります。
We note that the protection offered by the QS Nonce is the same whether one router makes all the decrements in the rate request, or whether they are made at different routers along the path.
私たちは、1つのルータがレート要求ですべての減少をするか、またはそれらが経路に沿って異なったルータで作られていることにかかわらずQS Nonceによって提供された保護が同じであることに注意します。
The requirements for randomization for the sender and routers in setting `random' values in the QS Nonce are not stringent -- almost any form of pseudo-random numbers will do. The requirement is that the original value for the QS Nonce is not easily predictable by the receiver, and in particular, the nonce MUST NOT be easily determined from inspection of the rest of the packet or from previous packets. In particular, the nonce MUST NOT be based only on a combination of specific packet header fields. Thus, if two bits of the QS Nonce are changed by a router along the path, the receiver should not be able to guess those two bits from the other 28 bits in the QS Nonce.
送付者のための無作為化のための要件と'無作為'の値をQS Nonceにはめ込むことにおけるルータは厳しくはありません--ほとんどどんなフォームの擬似乱数も大丈夫です。 要件はQS Nonceにおける元の値が受信機で容易に予測できないということです、そして、特に、一回だけはパケットの残りの点検か前のパケットから容易に決定してはいけません。 特に、一回だけは特定のパケットヘッダーフィールドの組み合わせだけに基づいてはいけません。 したがって、経路に沿ったルータでQS Nonceの2ビットを変えるなら、受信機はQS Nonceで他の28ビットからそれらの2ビットを推測できないはずです。
An additional requirement is that the receiver cannot be able to tell, from the QS Nonce itself, which numbers in the QS Nonce were generated by the sender, and which were generated by routers along the path. This makes it harder for the receiver to infer the value of the original rate request, making it one step harder for the receiver to cheat.
追加要件は受信機がQS Nonce自身からQS Nonceのどの数が送付者によって発生したか、そして、どれが経路に沿ったルータで発生したかを言うことができるはずがないということです。 これで、受信機がオリジナルのレート要求の値を推論するのが、より困難になります、それを受信機には、だますのが、より困難であるワンステップにして。
Section 9.4 also considers issues of receiver cheating in more detail.
また、セクション9.4はさらに詳細に受信機の不正行為することの問題を考えます。
Floyd, et al. Experimental [Page 17] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[17ページ]RFC4782クィックスタートとIP2007年1月
4. The Quick-Start Mechanisms in TCP
4. TCPのクィックスタートメカニズム
This section describes how the Quick-Start mechanism would be used in TCP. We first sketch the procedure and then tightly define it in the subsequent subsections.
このセクションはクィック-スタートメカニズムがTCPでどう使用されるだろうかを説明します。 私たちは、最初に、手順についてスケッチして、次に、その後の小区分でしっかりそれを定義します。
If a TCP sender (say, host A) would like to use Quick-Start, the TCP sender puts the requested sending rate in bits per second, appropriately formatted, in the Quick-Start Option in the IP header of the TCP packet, called the Quick-Start Request packet. (We will be somewhat loose in our use of "packet" vs. "segment" in this section.) When used for initial start-up, the Quick-Start Request packet can be either the SYN or SYN/ACK packet, as illustrated in Figure 1. The requested rate includes an estimate for the transport and IP header overhead. The TCP receiver (say, host B) returns the Quick-Start Response option in the TCP header in the responding SYN/ACK packet or ACK packet, called the Quick-Start Response packet, informing host A of the results of their request.
TCP送付者(たとえば、Aを接待する)がクィック-始めを使用したいと思うなら、TCP送付者はクィック-スタートRequestパケットと呼ばれるTCPパケットのIPヘッダーのクィック-スタートOptionで適切にフォーマットされたbpsに要求された送付レートを入れます。 (私たちはこのセクションで「セグメント」に対していくらか自由に私たちの「パケット」の使用でなるでしょう。) 上にから始まるのに初期の使用されると、クィック-スタートRequestパケットは、SYNかSYN/ACKパケットであるかもしれません、図1で例証されるように。 要求されたレートは輸送とIPヘッダーオーバーヘッドのための見積りを含んでいます。 TCP受信機(たとえば、Bを接待する)は彼らの要求の結果についてホストAに知らせるクィック-スタートResponseパケットと呼ばれる応じているSYN/ACKパケットかACKパケットのTCPヘッダーでクィック-スタートResponseオプションを返します。
If the acknowledging packet does not contain a Quick-Start Response, or contains a Quick-Start Response with the wrong value for the TTL Diff or the QS Nonce, then host A MUST assume that its Quick-Start request failed. In this case, host A sends a Report of Approved Rate with a Rate Report of zero, and uses TCP's default congestion control procedure. For initial start-up, host A uses the default initial congestion window ([RFC2581], [RFC3390]).
承認パケットがクィック-スタートResponseを含んでいないか、またはTTL DiffかQS Nonceのための間違った値があるクィック-スタートResponseを含んでいるなら、ホストAは、クィック-スタート要求が失敗したと仮定しなければなりません。 この場合、ホストAは、ゼロのRate ReportとApproved RateのReportを送って、TCPのデフォルト輻輳制御手順を用います。 [RFC3390)、上にから始まるように、初期のホストAはデフォルト初期の混雑ウィンドウ[RFC2581]を使用します。
If the returning packet contains a valid Quick-Start Response, then host A uses the information in the response, along with its measurement of the round-trip time, to determine the Quick-Start congestion window (QS-cwnd). Quick-Start data packets are defined as data packets sent as the result of a successful Quick-Start request, up to the time when the first Quick-Start packet is acknowledged. The sender also sends a Report of Approved Rate. In order to use Quick-Start, the TCP host MUST use rate-based pacing [VH97] to transmit Quick-Start packets at the rate indicated in the Quick-Start Response, at the level of granularity possible by the sending host. We note that the limitations of interrupt timing on computers can limit the ability of the TCP host in rate-pacing the outgoing packets.
戻っているパケットが有効なクィック-スタートResponseを含んでいるなら、ホストAは、クィック-スタート混雑ウィンドウ(QS-cwnd)を決定するのに往復の現代の測定に伴う応答に情報を使用します。 迅速なスタートデータ・パケットはうまくいっているクィック-スタート要求の結果として発信した最初のクィック-スタートパケットが承認される時まで定義されます。 また、送付者はApproved RateのReportを送ります。 クィック-始めを使用して、TCPホストはクィック-スタートResponseで示されたレートでクィック-スタートパケットを伝えるのに、レートベースのペース[VH97]を使用しなければなりません、送付ホストが可能な粒状のレベルで。 私たちは、コンピュータにおける中断タイミングの制限が出発しているパケットにレートで歩調を合わせることにおける、TCPホストの能力を制限できることに注意します。
The two TCP end-hosts can independently decide whether to request Quick-Start. For example, host A could send a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request in the SYN/ACK packet.
2人のTCP終わりホストが、クィック-始めを要求するかどうか独自に決めることができます。 例えば、ホストAはSYNパケットでクィック-スタートRequestを送ることができました、そして、また、ホストBはSYN/ACKパケットでクィック-スタートRequestを送ることができました。
Floyd, et al. Experimental [Page 18] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[18ページ]RFC4782クィックスタートとIP2007年1月
4.1. Sending the Quick-Start Request
4.1. クィックスタート要求を送ります。
When sending a Quick-Start Request, the TCP sender SHOULD send the request on a packet that requires an acknowledgement, such as a SYN, SYN/ACK, or data packet. In this case, if the packet is acknowledged but no Quick-Start Response is included, then the sender knows that the Quick-Start Request has been denied, and can send a Report of Approved Rate.
クィック-スタートRequestを送るとき、TCP送付者SHOULDは承認を必要とするパケットに関する要求を送ります、SYN、SYN/ACK、またはデータ・パケットなどのように。 この場合、パケットが承認されていますが、どんなクィック-スタートResponseも含まれていないなら、送付者は、クィック-スタートRequestが否定されて、Approved RateのReportを送ることができるのを知っています。
In addition to the use of Quick-Start when a connection is established, there are several additional points in a connection when a transport protocol may want to issue a Rate Request. We first reiterate the notion that Quick-Start is a coarse-grained mechanism. That is, Quick-Start's Rate Requests are not meant to be used for fine-grained control of the transport's sending rate. Rather, the transport MAY issue a Rate Request when no information about the appropriate sending rate is available, and the default congestion control mechanisms might be significantly underestimating the appropriate sending rate.
トランスポート・プロトコルがRate Requestを発行したがっているとき、接続が確立されるときのクィック-始めの使用に加えて、接続には追加数ポイントがあります。 私たちは最初に、クィック-始めが下品なメカニズムであるという概念を繰り返します。 すなわち、クィック始めのRate Requestsは輸送の送付レートのきめ細かに粒状のコントロールに使用されることになっていません。 適切な送付レートのどんな情報も利用可能でないときに、むしろ、輸送はRate Requestを発行するかもしれません、そして、デフォルト混雑制御機構は適切な送付レートをかなり過小評価しているかもしれません。
The following are potential points where Quick-Start may be useful:
↓これはクィック-始めが役に立つかもしれない潜在的ポイントです:
(1) At or soon after connection initiation, when the transport has no
idea of the capacity of the network path, as discussed above. (A
transport that uses TCP Control Block sharing [RFC2140], the
Congestion Manager [RFC3124], or other mechanisms for sharing
congestion information may not need Quick-Start to determine an
appropriate rate.)
(1) 輸送にネットワーク経路の容量の考えが全くすぐ後において、または、接続開始のすぐ後上で議論するようにないときに時。 (混雑情報を共有するのにTCP Control Block共有[RFC2140]、Congestionマネージャ[RFC3124]、または他のメカニズムを使用する輸送は適切なレートを測定するためにクィック-始めを必要としないかもしれません。)
(2) After an idle period when the transport no longer has a validated
estimate of the available bandwidth for this flow. (An example
could be a persistent-HTTP connection when a new HTTP request is
received after an idle period.)
活動していない期間の輸送にはこの流れのための利用可能な帯域幅の有効にされた見積りがもうない後(2)。 (活動していない期間の後に新しいHTTP要求を受け取るとき、例はしつこいHTTP接続であるかもしれません。)
(3) After a host has received explicit indications that one of the
endpoints has moved its point of network attachment. This can
happen due to some underlying mobility mechanism like Mobile IP
([RFC3344], [RFC3775]). Some transports, such as Steam Control
Transmission Protocol (SCTP) [RFC2960], may associate with
multiple IP addresses and can switch addresses (and therefore
network paths) in mid-connection. If the transport has concrete
knowledge of a changing network path, then the current sending
rate may not be appropriate, and the transport sender may use
Quick-Start to probe the network to see if it can send at a
higher rate. (Alternatively, traditional slow-start should be
used in this case when Quick-Start is not available.)
(3) ホストが終点のひとりがネットワーク付属のポイントを動かしたという明白な指摘を受けた後に。 [RFC3775)、これはモバイルIP[RFC3344]のような何らかの基本的な移動性メカニズムのため起こることができます。 Steam Control Transmissionプロトコルなどのいくつかの輸送(SCTP)[RFC2960]が、複数のIPアドレスと交際するかもしれなくて、中間の接続でアドレス(そして、したがって、ネットワーク経路)を切り換えることができます。 輸送に変化ネットワーク経路に関する具体的な知識があるなら、現在の送付レートは適切でないかもしれません、そして、輸送送付者はそれが、より高いレートで発信できるかどうかを見るためにネットワークを調べるのにクィック-始めを使用するかもしれません。 (クィック-始めがこの場合利用可能でないときに、あるいはまた、伝統的な遅れた出発は使用されるべきです。)
Floyd, et al. Experimental [Page 19] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[19ページ]RFC4782クィックスタートとIP2007年1月
(4) After an application-limited period, when the sender has been
using only a small amount of its appropriate share of the network
capacity and has no valid estimate for its fair share. In this
case, Quick-Start may be an appropriate mechanism to determine if
the sender can send at a higher rate. For instance, consider an
application that steadily exchanges low- rate control messages
and suddenly needs to transmit a large amount of data.
(4) After an application-limited period, when the sender has been using only a small amount of its appropriate share of the network capacity and has no valid estimate for its fair share. In this case, Quick-Start may be an appropriate mechanism to determine if the sender can send at a higher rate. For instance, consider an application that steadily exchanges low- rate control messages and suddenly needs to transmit a large amount of data.
Of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time. Case (3) requires external notifications not presently defined for TCP or other transport protocols. Finally, a TCP SHOULD NOT use Quick- Start for case (4) at the current time. Case (4) requires further thought and investigation with regard to how the transport protocol could determine it was in a situation that would warrant transmitting a Quick-Start Request.
Of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time. Case (3) requires external notifications not presently defined for TCP or other transport protocols. Finally, a TCP SHOULD NOT use Quick- Start for case (4) at the current time. Case (4) requires further thought and investigation with regard to how the transport protocol could determine it was in a situation that would warrant transmitting a Quick-Start Request.
As a general guideline, a TCP sender SHOULD NOT request a sending rate larger than it is able to use over the next round-trip time of the connection (or over 100 ms, if the round-trip time is not known), except as required to round up the desired sending rate to the next- highest allowable request.
As a general guideline, a TCP sender SHOULD NOT request a sending rate larger than it is able to use over the next round-trip time of the connection (or over 100 ms, if the round-trip time is not known), except as required to round up the desired sending rate to the next- highest allowable request.
In any circumstances, the sender MUST NOT make a QS request if it has made a QS request within the most recent round-trip time.
In any circumstances, the sender MUST NOT make a QS request if it has made a QS request within the most recent round-trip time.
Section 4.7 discusses some of the issues of using Quick-Start at connection initiation, and Section 4.8 discusses issues that arise when Quick-Start is used to request a larger sending rate after an idle period.
Section 4.7 discusses some of the issues of using Quick-Start at connection initiation, and Section 4.8 discusses issues that arise when Quick-Start is used to request a larger sending rate after an idle period.
4.2. The Quick-Start Response Option in the TCP header
4.2. The Quick-Start Response Option in the TCP header
In order to approve the use of Quick-Start, the TCP receiver responds to the receipt of a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header. TCP's Quick-Start Response option is defined as follows:
In order to approve the use of Quick-Start, the TCP receiver responds to the receipt of a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header. TCP's Quick-Start Response option is defined as follows:
Floyd, et al. Experimental [Page 20] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 20] RFC 4782 Quick-Start for TCP and IP January 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length=8 | Resv. | Rate | TTL Diff | | | | |Request| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QS Nonce | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Quick-Start Response Option in the TCP Header.
Figure 5: The Quick-Start Response Option in the TCP Header.
The first byte of the Quick-Start Response option contains the option kind, identifying the TCP option.
The first byte of the Quick-Start Response option contains the option kind, identifying the TCP option.
The second byte of the Quick-Start Response option contains the option length in bytes. The length field MUST be set to 8 bytes.
The second byte of the Quick-Start Response option contains the option length in bytes. The length field MUST be set to 8 bytes.
The third byte of the Quick-Start Response option contains a four- bit Reserved field, and the four-bit allowed Rate Request, formatted as in the Quick-Start Rate Request option.
The third byte of the Quick-Start Response option contains a four- bit Reserved field, and the four-bit allowed Rate Request, formatted as in the Quick-Start Rate Request option.
The fourth byte of the TCP option contains the TTL Diff. The TTL Diff contains the difference between the IP TTL and QS TTL fields in the received Quick-Start Request packet, as calculated in equations (1) or (2) (depending on whether IPv4 or IPv6 is used).
The fourth byte of the TCP option contains the TTL Diff. The TTL Diff contains the difference between the IP TTL and QS TTL fields in the received Quick-Start Request packet, as calculated in equations (1) or (2) (depending on whether IPv4 or IPv6 is used).
Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two- bit Reserved field.
Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two- bit Reserved field.
We note that, while there are limitations on the potential size of the Quick-Start Response Option, a Quick-Start Response Option of eight bytes should not be a problem. The TCP Options field can contain up to 40 bytes. Other TCP options that might be used in a SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time Stamp (ten bytes), Window Scale (three bytes), and Selective Acknowledgments Permitted (two bytes).
We note that, while there are limitations on the potential size of the Quick-Start Response Option, a Quick-Start Response Option of eight bytes should not be a problem. The TCP Options field can contain up to 40 bytes. Other TCP options that might be used in a SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time Stamp (ten bytes), Window Scale (three bytes), and Selective Acknowledgments Permitted (two bytes).
4.3. TCP: Sending the Quick-Start Response
4.3. TCP: Sending the Quick-Start Response
An end host (say, host B) that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP TTL field, to the receiving TCP layer.
An end host (say, host B) that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP TTL field, to the receiving TCP layer.
If the TCP host is willing to permit the Quick-Start Request, then a Quick-Start Response option is included in the TCP header of the corresponding acknowledgement packet. The Rate Request in the Quick-Start Response option is set to the received value of the Rate Request in the Quick-Start Option, or to a lower value if the TCP
If the TCP host is willing to permit the Quick-Start Request, then a Quick-Start Response option is included in the TCP header of the corresponding acknowledgement packet. The Rate Request in the Quick-Start Response option is set to the received value of the Rate Request in the Quick-Start Option, or to a lower value if the TCP
Floyd, et al. Experimental [Page 21] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 21] RFC 4782 Quick-Start for TCP and IP January 2007
receiver is only willing to allow a lower Rate Request. The TTL Diff in the Quick-Start Response is set to the difference between the IP TTL value and the QS TTL value as given in equation (1) or (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in the Response is set to the received value of the QS Nonce in the Quick- Start Option.
receiver is only willing to allow a lower Rate Request. The TTL Diff in the Quick-Start Response is set to the difference between the IP TTL value and the QS TTL value as given in equation (1) or (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in the Response is set to the received value of the QS Nonce in the Quick- Start Option.
If an end host receives an IP packet with a Quick-Start Request with a rate request of zero, then that host SHOULD NOT send a Quick-Start Response.
If an end host receives an IP packet with a Quick-Start Request with a rate request of zero, then that host SHOULD NOT send a Quick-Start Response.
The Quick-Start Response MUST NOT be resent if it is lost in the network. Packet loss could be an indication of congestion on the return path, in which case it is better not to approve the Quick- Start Request.
The Quick-Start Response MUST NOT be resent if it is lost in the network. Packet loss could be an indication of congestion on the return path, in which case it is better not to approve the Quick- Start Request.
4.4. TCP: Receiving and Using the Quick-Start Response Packet
4.4. TCP: Receiving and Using the Quick-Start Response Packet
A TCP host (say, TCP host A) that sent a Quick-Start Request and receives a Quick-Start Response in an acknowledgement first checks that the Quick-Start Response is valid. The Quick-Start Response is valid if it contains the correct value for the TTL Diff, and an equal or lesser value for the Rate Request than that transmitted in the Quick-Start Request. In addition, if the received Rate Request is K, then the rightmost 2K bits of the QS Nonce must match those bits in the QS Nonce sent in the Quick-Start Request. If these checks are not successful, then the Quick-Start Request failed, and the TCP host MUST use the default TCP congestion window that it would have used without Quick-Start. If the rightmost 2K bits of the QS Nonce do not match those bits in the QS Nonce sent in the Quick-Start Request, for a received Rate Request of K, then the TCP host MUST NOT send additional Quick-Start Requests during the life of the connection. Whether or not the Quick-Start Request was successful, the host receiving the Quick-Start Response MUST send a Report of Approved Rate. Similarly, if the packet containing the Quick-Start Request is acknowledged, but the acknowledgement does not include a Quick-Start Response, then the sender MUST send a Report of Approved Rate.
A TCP host (say, TCP host A) that sent a Quick-Start Request and receives a Quick-Start Response in an acknowledgement first checks that the Quick-Start Response is valid. The Quick-Start Response is valid if it contains the correct value for the TTL Diff, and an equal or lesser value for the Rate Request than that transmitted in the Quick-Start Request. In addition, if the received Rate Request is K, then the rightmost 2K bits of the QS Nonce must match those bits in the QS Nonce sent in the Quick-Start Request. If these checks are not successful, then the Quick-Start Request failed, and the TCP host MUST use the default TCP congestion window that it would have used without Quick-Start. If the rightmost 2K bits of the QS Nonce do not match those bits in the QS Nonce sent in the Quick-Start Request, for a received Rate Request of K, then the TCP host MUST NOT send additional Quick-Start Requests during the life of the connection. Whether or not the Quick-Start Request was successful, the host receiving the Quick-Start Response MUST send a Report of Approved Rate. Similarly, if the packet containing the Quick-Start Request is acknowledged, but the acknowledgement does not include a Quick-Start Response, then the sender MUST send a Report of Approved Rate.
If the checks of the TTL Diff and the Rate Request are successful, and the TCP host is going to use the Quick-Start Request, it MUST start using it within one round-trip time of receiving the Quick- Start Response, or within three seconds, whichever is smaller. To use the Quick-Start Request, the host sets its Quick-Start congestion window (in terms of MSS-sized segments), QS-cwnd, as follows:
If the checks of the TTL Diff and the Rate Request are successful, and the TCP host is going to use the Quick-Start Request, it MUST start using it within one round-trip time of receiving the Quick- Start Response, or within three seconds, whichever is smaller. To use the Quick-Start Request, the host sets its Quick-Start congestion window (in terms of MSS-sized segments), QS-cwnd, as follows:
QS-cwnd = (R * T) / (MSS + H) (3)
QS-cwnd = (R * T) / (MSS + H) (3)
Floyd, et al. Experimental [Page 22] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 22] RFC 4782 Quick-Start for TCP and IP January 2007
where R is the Rate Request in bytes per second, T is the measured round-trip time in seconds, and H is the estimated TCP/IP header size in bytes (e.g., 40 bytes).
where R is the Rate Request in bytes per second, T is the measured round-trip time in seconds, and H is the estimated TCP/IP header size in bytes (e.g., 40 bytes).
Derivation: the sender is allowed to transmit at R bytes per second including packet headers, but only R*MSS/(MSS+H) bytes per second, or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of application data.
Derivation: the sender is allowed to transmit at R bytes per second including packet headers, but only R*MSS/(MSS+H) bytes per second, or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of application data.
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored. If QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start mode, and while in Quick-Start mode, the TCP sender MUST use rate- based pacing to pace out Quick-Start packets at the approved rate. If, during Quick-Start mode, the TCP sender receives ACKs for packets sent before this Quick-Start mode was entered, these ACKs are processed as usual, following the default congestion control mechanisms. Quick-Start mode ends when the TCP host receives an ACK for one of the Quick-Start packets.
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored. If QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start mode, and while in Quick-Start mode, the TCP sender MUST use rate- based pacing to pace out Quick-Start packets at the approved rate. If, during Quick-Start mode, the TCP sender receives ACKs for packets sent before this Quick-Start mode was entered, these ACKs are processed as usual, following the default congestion control mechanisms. Quick-Start mode ends when the TCP host receives an ACK for one of the Quick-Start packets.
If the congestion window has not been fully used when the first ack arrives ending the Quick-Start mode, then the congestion window is decreased to the amount that has actually been used so far. This is necessary because when the Quick-Start Response is received, the TCP sender's round-trip-time estimate might be longer than for succeeding round-trip times, e.g., because of delays at routers processing the IP Quick-Start Option, or because of delays at the receiver in responding to the Quick-Start Request packet. In this case, an overly large round-trip-time estimate could have caused the TCP sender to translate the approved Quick-Start sending rate in bytes per second into a congestion window that is larger than needed, with the TCP sender receiving an ACK for the first Quick- Start packet before the entire congestion window has been used. Thus, when the TCP sender receives the first ACK for a Quick-Start packet, the sender MUST reduce the congestion window to the amount that has actually been used.
If the congestion window has not been fully used when the first ack arrives ending the Quick-Start mode, then the congestion window is decreased to the amount that has actually been used so far. This is necessary because when the Quick-Start Response is received, the TCP sender's round-trip-time estimate might be longer than for succeeding round-trip times, e.g., because of delays at routers processing the IP Quick-Start Option, or because of delays at the receiver in responding to the Quick-Start Request packet. In this case, an overly large round-trip-time estimate could have caused the TCP sender to translate the approved Quick-Start sending rate in bytes per second into a congestion window that is larger than needed, with the TCP sender receiving an ACK for the first Quick- Start packet before the entire congestion window has been used. Thus, when the TCP sender receives the first ACK for a Quick-Start packet, the sender MUST reduce the congestion window to the amount that has actually been used.
As an example, a TCP sender with an approved Quick-Start Request of R KBps, B-byte packets including headers, and an RTT estimate of T seconds, would translate the Rate Request of R KBps to a congestion window of R*T/B packets. The TCP sender would send the Quick-Start packets rate-paced at R KBps. However, if the actual current round- trip time was T/2 seconds instead of T seconds, then the sender would begin to receive acknowledgements for Quick-Start packets after T/2 seconds. Following the paragraph above, the TCP sender would then reduce its congestion window from R*T/B to approximately R*T/(B*2) packets, the actual number of packets that were needed to fill the pipe at a sending rate of R KBps. (Note: this is just an
As an example, a TCP sender with an approved Quick-Start Request of R KBps, B-byte packets including headers, and an RTT estimate of T seconds, would translate the Rate Request of R KBps to a congestion window of R*T/B packets. The TCP sender would send the Quick-Start packets rate-paced at R KBps. However, if the actual current round- trip time was T/2 seconds instead of T seconds, then the sender would begin to receive acknowledgements for Quick-Start packets after T/2 seconds. Following the paragraph above, the TCP sender would then reduce its congestion window from R*T/B to approximately R*T/(B*2) packets, the actual number of packets that were needed to fill the pipe at a sending rate of R KBps. (Note: this is just an
Floyd, et al. Experimental [Page 23] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 23] RFC 4782 Quick-Start for TCP and IP January 2007
illustration; the congestion window is actually set to the amount of data sent before the ACK arrives and not based on equations above.)
illustration; the congestion window is actually set to the amount of data sent before the ACK arrives and not based on equations above.)
After Quick-Start mode is exited and the congestion window adjusted if necessary, the TCP sender returns to using the default congestion- control mechanisms, processing further incoming ACK packets as specified by those congestion control mechanisms. For example, if the TCP sender was in slow-start prior to the Quick-Start Request, and no packets were lost or marked since that time, then the sender continues in slow-start after exiting Quick-Start mode, as allowed by ssthresh.
After Quick-Start mode is exited and the congestion window adjusted if necessary, the TCP sender returns to using the default congestion- control mechanisms, processing further incoming ACK packets as specified by those congestion control mechanisms. For example, if the TCP sender was in slow-start prior to the Quick-Start Request, and no packets were lost or marked since that time, then the sender continues in slow-start after exiting Quick-Start mode, as allowed by ssthresh.
To add robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP sender limits the number of packets by which the congestion window is increased for one window of data during slow-start.
To add robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP sender limits the number of packets by which the congestion window is increased for one window of data during slow-start.
When Quick-Start is used at the beginning of a connection, before any packet marks or losses have been reported, the TCP host MAY use the reported Rate Request to set the slow-start threshold to a desired value, e.g., to some small multiple of the congestion window. A possible future research topic is how the sender might modify the slow-start threshold at the beginning of a connection to avoid overshooting the path capacity. (The initial value of ssthresh is allowed to be arbitrarily high, and some TCP implementations use the size of the advertised window for ssthresh [RFC2581].)
When Quick-Start is used at the beginning of a connection, before any packet marks or losses have been reported, the TCP host MAY use the reported Rate Request to set the slow-start threshold to a desired value, e.g., to some small multiple of the congestion window. A possible future research topic is how the sender might modify the slow-start threshold at the beginning of a connection to avoid overshooting the path capacity. (The initial value of ssthresh is allowed to be arbitrarily high, and some TCP implementations use the size of the advertised window for ssthresh [RFC2581].)
4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path
4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path
When a Quick-Start Request is approved for a TCP sender, the resulting Quick-Start data traffic can result in a sudden increase in traffic for pure ACK packets on the reverse path. For example, for the largest Quick-Start Request of 1.3 Gbps, given a TCP sender with 1500-byte packets and a TCP receiver with delayed acknowledgements acking every other packet, this could result in 17.3 Mbps of acknowledgement traffic on the reverse path.
When a Quick-Start Request is approved for a TCP sender, the resulting Quick-Start data traffic can result in a sudden increase in traffic for pure ACK packets on the reverse path. For example, for the largest Quick-Start Request of 1.3 Gbps, given a TCP sender with 1500-byte packets and a TCP receiver with delayed acknowledgements acking every other packet, this could result in 17.3 Mbps of acknowledgement traffic on the reverse path.
One possibility, in cases with large Quick-Start Requests, would be for TCP receivers to send Quick-Start Requests to request bandwidth for the acknowledgement traffic on the reverse path. However, in our view, a better approach would be for TCP receivers to simply control the rate of sending acknowledgement traffic. The optimal future solution would involve the explicit use of congestion control for TCP acknowledgement traffic, as is done now for the acknowledgement traffic in DCCP's CCID2 [RFC4341].
One possibility, in cases with large Quick-Start Requests, would be for TCP receivers to send Quick-Start Requests to request bandwidth for the acknowledgement traffic on the reverse path. However, in our view, a better approach would be for TCP receivers to simply control the rate of sending acknowledgement traffic. The optimal future solution would involve the explicit use of congestion control for TCP acknowledgement traffic, as is done now for the acknowledgement traffic in DCCP's CCID2 [RFC4341].
Floyd, et al. Experimental [Page 24] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 24] RFC 4782 Quick-Start for TCP and IP January 2007
In the absence of congestion control for acknowledgement traffic, the TCP receiver could limit its sending rate for ACK packets sent in response to Quick-Start data packets. The following information is needed by the TCP receiver:
In the absence of congestion control for acknowledgement traffic, the TCP receiver could limit its sending rate for ACK packets sent in response to Quick-Start data packets. The following information is needed by the TCP receiver:
* The RTT: TCP naturally measures the RTT of the path and therefore
should have a sample of the RTT. If the TCP receiver does not have
a measurement of the round-trip time, it can use the time between
the receipt of the Quick-Start Request and the Report of Approved
Rate.
* The RTT: TCP naturally measures the RTT of the path and therefore should have a sample of the RTT. If the TCP receiver does not have a measurement of the round-trip time, it can use the time between the receipt of the Quick-Start Request and the Report of Approved Rate.
* The Approved Rate Request (R): When the TCP receiver receives the
Quick-Start Response packet, the receiver knows the value of the
approved Rate Request.
* The Approved Rate Request (R): When the TCP receiver receives the Quick-Start Response packet, the receiver knows the value of the approved Rate Request.
* The MSS: TCP advertises the MSS during the initial three-way
handshake; therefore, the receiver should have an understanding of
the packet size the sender will be using. If the receiver does not
have such an understanding or wishes to confirm the negotiated MSS,
the size of the first data packet can be used.
* The MSS: TCP advertises the MSS during the initial three-way handshake; therefore, the receiver should have an understanding of the packet size the sender will be using. If the receiver does not have such an understanding or wishes to confirm the negotiated MSS, the size of the first data packet can be used.
With this set of information, the TCP receiver can restrict its sending rate for pure acknowledgment traffic to at most 100 pure ACK packets per RTT by sending at most one ACK for every K data packets, for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would acknowledge the first Quick-Start data packet, and every succeeding K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps, RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the receiver would acknowledge every 216 data packets. From [RFC2581], the ACK Ratio K should have a minimum value of two. When the ACK Ratio is greater than two, and the TCP sender receives acknowledgements each acknowledging more than two data packets, the TCP sender may want to use rate-based pacing to control the burstiness of its outgoing data traffic.
With this set of information, the TCP receiver can restrict its sending rate for pure acknowledgment traffic to at most 100 pure ACK packets per RTT by sending at most one ACK for every K data packets, for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would acknowledge the first Quick-Start data packet, and every succeeding K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps, RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the receiver would acknowledge every 216 data packets. From [RFC2581], the ACK Ratio K should have a minimum value of two. When the ACK Ratio is greater than two, and the TCP sender receives acknowledgements each acknowledging more than two data packets, the TCP sender may want to use rate-based pacing to control the burstiness of its outgoing data traffic.
In the absence of explicit congestion control mechanisms, the TCP end nodes cannot determine the packet drop rate for pure acknowledgement traffic. This is true with or without Quick-Start. However, the TCP receiver could limit its increase in the sending rate for pure ACK packets by at most doubling the sending rate for pure ACK packets from one round-trip time to the next. The TCP receiver would do this by halving the ACK Ratio each round-trip time.
In the absence of explicit congestion control mechanisms, the TCP end nodes cannot determine the packet drop rate for pure acknowledgement traffic. This is true with or without Quick-Start. However, the TCP receiver could limit its increase in the sending rate for pure ACK packets by at most doubling the sending rate for pure ACK packets from one round-trip time to the next. The TCP receiver would do this by halving the ACK Ratio each round-trip time.
Note that the above is one particular mechanism that could be used to control the ACK stream. Future work that investigates this scheme and others in detail is encouraged.
Note that the above is one particular mechanism that could be used to control the ACK stream. Future work that investigates this scheme and others in detail is encouraged.
Floyd, et al. Experimental [Page 25] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 25] RFC 4782 Quick-Start for TCP and IP January 2007
4.6. TCP: Responding to a Loss of a Quick-Start Packet
4.6. TCP: Responding to a Loss of a Quick-Start Packet
For TCP, we have defined a "Quick-Start packet" as one of the packets sent in the window immediately following a successful Quick-Start Request. After detecting the loss or ECN-marking of a Quick-Start packet, TCP MUST revert to the default congestion control procedures that would have been used if the Quick-Start Request had not been approved. For example, if Quick-Start is used for setting the initial window, and a packet from the initial window is lost or marked, then the TCP sender MUST then slow-start with the default initial window that would have been used if Quick-Start had not been used. In addition to reverting to the default congestion control mechanisms, the sender MUST take into account that the Quick-Start congestion window was too large. Thus, the sender SHOULD decrease ssthresh to, at most, half the number of Quick-Start packets that were successfully transmitted. Appendix B.5 discusses possible alternatives in responding to the loss of a Quick-Start packet.
For TCP, we have defined a "Quick-Start packet" as one of the packets sent in the window immediately following a successful Quick-Start Request. After detecting the loss or ECN-marking of a Quick-Start packet, TCP MUST revert to the default congestion control procedures that would have been used if the Quick-Start Request had not been approved. For example, if Quick-Start is used for setting the initial window, and a packet from the initial window is lost or marked, then the TCP sender MUST then slow-start with the default initial window that would have been used if Quick-Start had not been used. In addition to reverting to the default congestion control mechanisms, the sender MUST take into account that the Quick-Start congestion window was too large. Thus, the sender SHOULD decrease ssthresh to, at most, half the number of Quick-Start packets that were successfully transmitted. Appendix B.5 discusses possible alternatives in responding to the loss of a Quick-Start packet.
If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD NOT make future Quick-Start Requests for this connection.
If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD NOT make future Quick-Start Requests for this connection.
We note that ECN [RFC3168] MAY be used with Quick-Start. As is always the case with ECN, the sender's congestion control response to an ECN-marked Quick-Start packet is the same as the response to a dropped Quick-Start packet, thus reverting to slow start in the case of Quick-Start packets marked as experiencing congestion.
We note that ECN [RFC3168] MAY be used with Quick-Start. As is always the case with ECN, the sender's congestion control response to an ECN-marked Quick-Start packet is the same as the response to a dropped Quick-Start packet, thus reverting to slow start in the case of Quick-Start packets marked as experiencing congestion.
4.7. TCP: A Quick-Start Request for a Larger Initial Window
4.7. TCP: A Quick-Start Request for a Larger Initial Window
Some of the issues of using Quick-Start are related to the specific scenario in which Quick-Start is used. This section discusses the following issues that arise when Quick-Start is used by TCP to request a larger initial window: (1) interactions with Path MTU Discovery (PMTUD); and (2) Quick-Start Request packets that are discarded by middleboxes.
Some of the issues of using Quick-Start are related to the specific scenario in which Quick-Start is used. This section discusses the following issues that arise when Quick-Start is used by TCP to request a larger initial window: (1) interactions with Path MTU Discovery (PMTUD); and (2) Quick-Start Request packets that are discarded by middleboxes.
4.7.1. Interactions with Path MTU Discovery
4.7.1. Interactions with Path MTU Discovery
One issue when Quick-Start is used to request a large initial window concerns the interactions between the large initial window and Path MTU Discovery. Some of the issues are discussed in RFC 3390:
One issue when Quick-Start is used to request a large initial window concerns the interactions between the large initial window and Path MTU Discovery. Some of the issues are discussed in RFC 3390:
"When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the `Don't Fragment' (DF) bit in all segments in the initial window, or to set the `Don't Fragment' (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best."
"When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the `Don't Fragment' (DF) bit in all segments in the initial window, or to set the `Don't Fragment' (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best."
Floyd, et al. Experimental [Page 26] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 26] RFC 4782 Quick-Start for TCP and IP January 2007
If the sender knows the Path MTU when the initial window is sent (e.g., from a PMTUD cache or from some other IETF-approved method), then the sender SHOULD use that MTU for segments in the initial window. Unfortunately, the sender doesn't necessarily know the Path MTU when it sends packets in the initial window. In this case, the sender should be conservative in the packet size used. Sending a large number of overly large packets with the DF bit set is not desirable, but sending a large number of packets that are fragmented in the network can be equally undesirable.
If the sender knows the Path MTU when the initial window is sent (e.g., from a PMTUD cache or from some other IETF-approved method), then the sender SHOULD use that MTU for segments in the initial window. Unfortunately, the sender doesn't necessarily know the Path MTU when it sends packets in the initial window. In this case, the sender should be conservative in the packet size used. Sending a large number of overly large packets with the DF bit set is not desirable, but sending a large number of packets that are fragmented in the network can be equally undesirable.
If the sender doesn't know the Path MTU when the initial window is sent, the sender SHOULD send one large packet in the initial window with the DF bit set, and send the remaining packets in the initial window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
If the sender doesn't know the Path MTU when the initial window is sent, the sender SHOULD send one large packet in the initial window with the DF bit set, and send the remaining packets in the initial window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
A second possibility would be for the sender to delay sending the Quick-Start Request for one round-trip time by sending the Quick- Start Request with the first window of data, while also doing Path MTU Discovery.
A second possibility would be for the sender to delay sending the Quick-Start Request for one round-trip time by sending the Quick- Start Request with the first window of data, while also doing Path MTU Discovery.
The sender may be using an iterative approach such as Packetization Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, where the sender tests successively larger MTUs. If a probe is successfully delivered, then the MTU can be raised to reflect the value used in that probe. We would note that PLPMTUD does not allow the sender to determine the Path MTU before sending the initial window of data.
The sender may be using an iterative approach such as Packetization Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, where the sender tests successively larger MTUs. If a probe is successfully delivered, then the MTU can be raised to reflect the value used in that probe. We would note that PLPMTUD does not allow the sender to determine the Path MTU before sending the initial window of data.
4.7.2. Quick-Start Request Packets that are Discarded by Routers or
Middleboxes
4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes
It is always possible for a TCP SYN packet carrying a Quick-Start request to be dropped in the network due to congestion, or to be blocked due to interactions with routers or middleboxes, where a middlebox is defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host [RFC3234]. Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the Web servers investigated, no connection is established if the TCP SYN packet contains an unknown IP option (and for 43% of the Web servers, no connection is established if the TCP SYN packet contains an IP TimeStamp Option). In both cases, this is presumably due to routers or middleboxes along that path.
It is always possible for a TCP SYN packet carrying a Quick-Start request to be dropped in the network due to congestion, or to be blocked due to interactions with routers or middleboxes, where a middlebox is defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host [RFC3234]. Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the Web servers investigated, no connection is established if the TCP SYN packet contains an unknown IP option (and for 43% of the Web servers, no connection is established if the TCP SYN packet contains an IP TimeStamp Option). In both cases, this is presumably due to routers or middleboxes along that path.
If the TCP sender doesn't receive a response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request.
If the TCP sender doesn't receive a response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request.
Floyd, et al. Experimental [Page 27] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 27] RFC 4782 Quick-Start for TCP and IP January 2007
Similarly, if the TCP sender receives a TCP reset in response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request [RFC3360].
Similarly, if the TCP sender receives a TCP reset in response to the SYN or SYN/ACK packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request [RFC3360].
RFCs 1122 and 2988 specify that the sender should set the initial RTO (retransmission timeout) to three seconds, though many TCP implementations set the initial RTO to one second. For a TCP SYN packet sent with a Quick-Start request, the TCP sender SHOULD use an initial RTO of three seconds.
RFCs 1122 and 2988 specify that the sender should set the initial RTO (retransmission timeout) to three seconds, though many TCP implementations set the initial RTO to one second. For a TCP SYN packet sent with a Quick-Start request, the TCP sender SHOULD use an initial RTO of three seconds.
We note that if the TCP SYN packet is using the IP Quick-Start Option for a Quick-Start Request, and it is also using bits in the TCP header to negotiate ECN-capability with the TCP host at the other end, then the drop of a TCP SYN packet could be due to congestion, a router or middlebox dropping the packet because of the IP Option, or a router or middlebox dropping the packet because of the information in the TCP header negotiating ECN. In this case, the sender could resend the dropped packet without either the Quick-Start or the ECN requests. Alternately, the sender could resend the dropped packet with only the ECN request in the TCP header, resending the TCP SYN packet without either the Quick-Start or the ECN requests if the second TCP SYN packet is dropped. The second choice seems reasonable, given that a TCP SYN packet today is more likely to be blocked due to policies that discard packets with IP Options than due to policies that discard packets with ECN requests in the TCP header [MAF04].
We note that if the TCP SYN packet is using the IP Quick-Start Option for a Quick-Start Request, and it is also using bits in the TCP header to negotiate ECN-capability with the TCP host at the other end, then the drop of a TCP SYN packet could be due to congestion, a router or middlebox dropping the packet because of the IP Option, or a router or middlebox dropping the packet because of the information in the TCP header negotiating ECN. In this case, the sender could resend the dropped packet without either the Quick-Start or the ECN requests. Alternately, the sender could resend the dropped packet with only the ECN request in the TCP header, resending the TCP SYN packet without either the Quick-Start or the ECN requests if the second TCP SYN packet is dropped. The second choice seems reasonable, given that a TCP SYN packet today is more likely to be blocked due to policies that discard packets with IP Options than due to policies that discard packets with ECN requests in the TCP header [MAF04].
4.8. TCP: A Quick-Start Request in the Middle of a Connection
4.8. TCP: A Quick-Start Request in the Middle of a Connection
This section discusses the following issues that arise when Quick- Start is used by TCP to request a larger window in the middle of a connection, such as after an idle period: (1) determining the rate to request; (2) when to make a request; and (3) the response if Quick- Start packets are dropped.
This section discusses the following issues that arise when Quick- Start is used by TCP to request a larger window in the middle of a connection, such as after an idle period: (1) determining the rate to request; (2) when to make a request; and (3) the response if Quick- Start packets are dropped.
(1) Determining the rate to request:
For a connection that has not yet had a congestion event (that
is, a marked or dropped packet), the TCP sender is not restricted
in the rate that it requests. As an example, a server might wait
and send a Quick-Start Request after a short interaction with the
client.
(1) Determining the rate to request: For a connection that has not yet had a congestion event (that is, a marked or dropped packet), the TCP sender is not restricted in the rate that it requests. As an example, a server might wait and send a Quick-Start Request after a short interaction with the client.
To use a Quick-Start Request in a connection that has already
experienced a congestion event, and that has not had a recent
mobility event, the TCP sender can determine the largest
congestion window that the TCP connection achieved since the last
packet drop and translate this to a sending rate to get the
To use a Quick-Start Request in a connection that has already experienced a congestion event, and that has not had a recent mobility event, the TCP sender can determine the largest congestion window that the TCP connection achieved since the last packet drop and translate this to a sending rate to get the
Floyd, et al. Experimental [Page 28] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 28] RFC 4782 Quick-Start for TCP and IP January 2007
maximum allowed request rate. If the request is granted, then
the sender essentially restarts with its old congestion window
from before it was reduced, for example, during an idle period.
maximum allowed request rate. If the request is granted, then the sender essentially restarts with its old congestion window from before it was reduced, for example, during an idle period.
A Quick-Start Request sent in the middle of a TCP connection
SHOULD be sent on a data packet.
A Quick-Start Request sent in the middle of a TCP connection SHOULD be sent on a data packet.
(2) When to make a request:
A TCP connection MAY make a Quick-Start Request before the
connection has experienced a congestion event, or after an idle
period of at least one RTO.
(2) 造のa要求に: TCP接続は接続が混雑出来事を経験する前、または少なくとも1RTOの活動していない期間の後にクィック-始めをRequestにするかもしれません。
(3) Response if Quick-Start packets are dropped:
If Quick-Start packets are dropped in the middle of connection,
then the sender MUST revert to half the Quick-Start window, or to
the congestion window that the sender would have used if the
Quick-Start request had not been approved, whichever is smaller.
(3) 応答はクィック-スタートパケットであるなら落とされます: クィック-スタートパケットが接続の途中で落とされるなら、送付者はクィック-スタートウィンドウの半分、または、クィック-スタート要求が承認されなかったなら送付者が使用した混雑ウィンドウに先祖帰りをしなければなりません、どれがさらに小さいかなら。
4.9. An Example Quick-Start Scenario with TCP
4.9. TCPがある例のクィックスタートシナリオ
The following is an example scenario of when both hosts request Quick-Start for setting their initial windows. This is similar to Figures 1 and 2 in Section 2.1, except that it illustrates a TCP connection with both TCP hosts sending Quick-Start Requests.
↓これは両方のホストが彼らの初期の窓を設定するためのクィック-始めを要求する時に関する例のシナリオです。 これはセクション2.1の図1と2と同様です、両方のTCPホスト送付クィック-スタートRequestsをTCP接続に入れるのを除いて。
* The TCP SYN packet from Host A contains a Quick-Start Request in
the IP header.
* Host AからのTCP SYNパケットはIPヘッダーにクィック-スタートRequestを含んでいます。
* Routers along the forward path modify the Quick-Start Request as
appropriate.
* フォワードパスに沿ったルータは適宜クィック-スタートRequestを変更します。
* Host B receives the Quick-Start Request in the SYN packet, and
calculates the TTL Diff. If Host B approves the Quick-Start
Request, then Host B sends a Quick-Start Response in the TCP header
of the SYN/ACK packet. Host B also sends a Quick-Start Request in
the IP header of the SYN/ACK packet.
* ホストBは、SYNパケットにクィック-スタートRequestを受け取って、TTL Diffについて計算します。 Host Bがクィック-スタートRequestを承認するなら、Host BはSYN/ACKパケットのTCPヘッダーでクィック-スタートResponseを送ります。 また、ホストBはSYN/ACKパケットのIPヘッダーでクィック-スタートRequestを送ります。
* Routers along the reverse path modify the Quick-Start Request as
appropriate.
* 逆の経路に沿ったルータは適宜クィック-スタートRequestを変更します。
* Host A receives the Quick-Start Response in the SYN/ACK packet, and
checks the TTL Diff, Rate Request, and QS Nonce for validity. If
they are valid, then Host A sets its initial congestion window
appropriately, and sets up rate-based pacing to be used with the
initial window. If the Quick-Start Response is not valid, then
Host A uses TCP's default initial window. In either case, Host A
sends a Report of Approved Rate.
* ホストAは、SYN/ACKパケットにクィック-スタートResponseを受け取って、正当性がないかどうかTTL Diff、Rate Request、およびQS Nonceをチェックします。 それらが有効であるなら、Host Aは、初期の窓と共に使用されるために適切に初期の混雑ウィンドウを設定して、レートベースのペースをセットアップします。 クィック-スタートResponseが有効でないなら、Host AはTCPのデフォルトの初期のウィンドウを使用します。 どちらの場合ではも、Host AはApproved RateのReportを送ります。
Floyd, et al. Experimental [Page 29] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[29ページ]RFC4782クィックスタートとIP2007年1月
Host A also calculates the TTL Diff for the Quick-Start Request in
the incoming SYN/ACK packet, and sends a Quick-Start Response in
the TCP header of the ACK packet.
ホストAは、また、入って来るSYN/ACKパケットでクィック-スタートRequestにTTL Diffについて計算して、ACKパケットのTCPヘッダーでクィック-スタートResponseを送ります。
* Host B receives the Quick-Start Response in an ACK packet, and
checks the TTL Diff, Rate Request, and QS Nonce for validity. If
the Quick-Start Response is valid, then Host B sets its initial
congestion window appropriately, and sets up rate-based pacing to
be used with its initial window. If the Quick-Start Response is
not valid, then Host B uses TCP's default initial window. In
either case, Host B sends a Report of Approved Rate.
* ホストBは、ACKパケットにクィック-スタートResponseを受け取って、正当性がないかどうかTTL Diff、Rate Request、およびQS Nonceをチェックします。 クィック-スタートResponseが有効であるなら、Host Bは、初期の窓と共に使用されるために適切に初期の混雑ウィンドウを設定して、レートベースのペースをセットアップします。 クィック-スタートResponseが有効でないなら、Host BはTCPのデフォルトの初期のウィンドウを使用します。 どちらの場合ではも、Host BはApproved RateのReportを送ります。
5. Quick-Start and IPsec AH
5. クィックスタートとIPsec、ああ。
This section shows that Quick-Start is compatible with IPsec Authentication Header (AH). AH uses an Integrity Check Value (ICV) in the IPsec Authentication Header to verify both message authentication and integrity [RFC4302]. Changes to the Quick-Start Option in the IP header do not affect this AH ICV. The tunnel considerations in Section 6 below apply to all IPsec tunnels, regardless of what IPsec headers or processing are used in conjunction with the tunnel.
このセクションは、クィック-始めはIPsec Authentication Header(AH)と互換性があるのを示します。 AHは、通報認証と保全[RFC4302]の両方について確かめるのに、IPsec Authentication HeaderでIntegrity Check Value(ICV)を使用します。 IPヘッダーのクィック-スタートOptionへの変化はこのAH ICVに影響しません。 以下のセクション6のトンネル問題はすべてのIPsecトンネルに適用されます、どんなIPsecヘッダーか処理がトンネルに関連して使用されるかにかかわらず。
Because the contents of the Quick-Start Option can change along the path, it is important that these changes not affect the IPsec Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC 4302 requires that unrecognized IPv4 options be zeroed for AH ICV computation purposes, so Quick-Start IP Option data changing en route does not cause problems with existing IPsec AH implementations for IPv4. If the Quick-Start Option is recognized, it MUST be treated as a mutable IPv4 option, and hence be completely zeroed for AH ICV calculation purposes. IPv6 option numbers explicitly indicate whether the option is mutable; the third-highest order bit in the IANA-allocated option type has the value 1 to indicate that the Quick-Start Option data can change en route. RFC 4302 requires that the option data of any such option be zeroed for AH ICV computation purposes. Therefore, changes to the Quick-Start Option in the IP header do not affect the calculation of the AH ICV.
クィック-スタートOptionのコンテンツが経路に沿って変化できるので、これらの変化がIPsec Authentication Header Integrity Check Value(AH ICV)に影響しないのは、重要です。 IPv4に関しては、RFC4302が、認識されていないIPv4オプションのゼロがAH ICV計算目的のために合わせられているのを必要とするので、途中で変化するクィック-スタートIP OptionデータはIPv4のために既存のIPsec AH実現で問題を起こしません。 クィック-スタートOptionが認識されるなら、無常のIPv4オプションとして扱われて、したがって、AH ICV計算目的のためにそれのゼロを完全に合わせなければなりません。 IPv6オプション番号は、オプションが無常であるかどうかを明らかに示します。 IANAによって割り当てられたオプションタイプにおける3番目に高いオーダービットには、クィック-スタートOptionデータが途中で変化できるのを示すために、値1があります。 RFC4302は、どんなそのようなオプションに関するオプションデータのゼロもAH ICV計算目的のために合わせられているのを必要とします。 したがって、IPヘッダーのクィック-スタートOptionへの変化はAH ICVの計算に影響しません。
Floyd, et al. Experimental [Page 30] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[30ページ]RFC4782クィックスタートとIP2007年1月
6. Quick-Start in IP Tunnels and MPLS
6. IP TunnelsとMPLSのクィックスタート
This section considers interactions between Quick-Start and IP tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE [RFC2784], and others. This section also considers interactions between Quick-Start and MPLS [RFC3031].
このセクションはIPsec([RFC4301])、IPにおけるIP[RFC2003]、GRE[RFC2784]、および他のものを含むクィック-始めとIPトンネルとの相互作用を考えます。 また、このセクションはクィック-始めとMPLS[RFC3031]との相互作用を考えます。
In the discussion, we use TTL Diff, defined earlier as the difference between the IP TTL and the Quick-Start TTL, mod 256. Recall that the sender considers the Quick-Start Request approved only if the value of TTL Diff for the packet entering the network is the same as the value of TTL Diff for the packet exiting the network.
議論では、私たちは、より早くIP TTLとクィック-スタートTTLの違い、モッズ風の256と定義されたTTL Diffを使用します。 ネットワークを出るパケットに、ネットワークに入るパケットのためのTTL Diffの値がTTL Diffの値と同じである場合にだけ送付者が、クィック-スタートRequestが承認されていると考えると思い出してください。
Simple tunnels: IP tunnel modes are generally based on adding a new "outer" IP header that encapsulates the original or "inner" IP header and its associated packet. In many cases, the new "outer" IP header may be added and removed at intermediate points along a path, enabling the network to establish a tunnel without requiring endpoint participation. We denote tunnels that specify that the outer header be discarded at tunnel egress as "simple tunnels", and we denote tunnels where the egress saves and uses information from the outer header before discarding it as "non-simple tunnels". An example of a "non-simple tunnel" would be a tunnel configured to support ECN, where the egress router might copy the ECN codepoint in the outer header to the inner header before discarding the outer header [RFC3168].
簡単なトンネル: 一般に、IPトンネルモードはオリジナルの、または、「内側」のIPヘッダーとその関連パケットをカプセルに入れる新しい「外側」のIPヘッダーを加えるのに基づいています。 多くの場合、経路に沿って新しい「外側」のIPヘッダーを加えて、中間的ポイントで取り除くかもしれません、ネットワークが終点参加を必要としないでトンネルを確立するのを可能にして。 私たちは外側のヘッダーが「簡単なトンネル」としてトンネル出口で捨てられると指定するトンネルを指示します、そして、「非単純トンネル」としてそれを捨てる前に出口が外側のヘッダーからの情報を保存して、使用するトンネルを指示します。 「非単純トンネル」に関する例は電子証券取引ネットワークを支持するために構成されたトンネルでしょう。(そこでは、外側のヘッダー[RFC3168]を捨てる前に、出口ルータが外側のヘッダーに内側のヘッダーに電子証券取引ネットワークcodepointをコピーするかもしれません)。
__ Tunnels Compatible with Quick-Start
/
Simple Tunnels __/
\
\__ Tunnels Not Compatible with Quick-Start
(False Positives!)
__ Tunnels Compatible with Quick-Start / Simple Tunnels __/ \ \__ Tunnels Not Compatible with Quick-Start (無病誤診!)
__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?
__クィックスタート//非単純Tunnels__/を支持しているTunnels_____ Tunnels Compatible with Quick-Start, \ but Not Supporting Quick-Start \ \__ Tunnels Not Compatible with Quick-Start?
Figure 6: Categories of Tunnels.
図6: Tunnelsのカテゴリ。
Floyd, et al. Experimental [Page 31] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[31ページ]RFC4782クィックスタートとIP2007年1月
Tunnels that are compatible with Quick-Start: We say that an IP tunnel `is not compatible with Quick-Start' if the use of a Quick- Start Request over such a tunnel allows false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. If the use of Quick-Start over the tunnel does not cause false positives, we say that the IP tunnel `is compatible with Quick-Start'.
クィック-始めと互換性があるトンネル: 私たちは、そのようなトンネルの上のクィックスタートRequestの使用がTCP送付者が、クィック-スタートRequestが経路に沿ったすべてのルータによって承認されたと不当に信じている無病誤診を許容するならIPトンネルは'クィック-始めと互換性がない'と言います。 トンネルの上のクィック-始めの使用が無病誤診を引き起こさないなら、私たちは、IPトンネルは'クィック-始めと互換性がある'と言います。
If the IP TTL of the inner header is decremented during forwarding before tunnel encapsulation takes place, then the simple tunnel is compatible with Quick-Start, with Quick-Start Requests being rejected. Section 6.1 describes in more detail the ways that a simple tunnel can be compatible with Quick-Start.
トンネルカプセル化が行われる前に内側のヘッダーのIP TTLが推進の間、減少するなら、簡単なトンネルはクィック-始めと互換性があります、クィック-スタートRequestsが拒絶されている状態で。 セクション6.1はさらに詳細に簡単なトンネルがクィック-始めと互換性がある場合がある方法を述べます。
There are some simple tunnels that are not compatible with Quick- Start, allowing `false positives' where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path. This is discussed in Section 6.2 below.
いくつかのクィック始めと互換性がない簡単なトンネルがあります、TCP送付者が、クィック-スタートRequestが経路に沿ったすべてのルータによって承認されたと不当に信じている'無病誤診'を許容して。 以下のセクション6.2でこれについて議論します。
One of our tasks in the future will be to investigate the occurrence of tunnels that are not compatible with Quick-Start, and to track the extent to which such tunnels are modified over time. The evaluation of the problem of false positives from tunnels that are not compatible with Quick-Start will affect the progression of Quick- Start from Experimental to Proposed Standard, and will affect the degree of deployment of Quick-Start while in Experimental mode.
未来の私たちのタスクの1つは、クィック-始めと互換性がないトンネルの発生を調査して、そのようなトンネルが時間がたつにつれて変更される範囲を追跡することでしょう。 クィック-始めと互換性がないトンネルからの無病誤診の問題の評価は、ExperimentalからProposed Standardまでのクィック始めの進行に影響して、Experimentalモードで影響している間、クィック-始めの展開の度合いに影響するでしょう。
Tunnels that support Quick-Start: We say that an IP tunnel `supports Quick-Start' if it allows routers along the tunnel path to process the Quick-Start Request and give feedback, resulting in the appropriate possible acceptance of the Quick-Start Request. Some tunnels that are compatible with Quick-Start support Quick-Start, while others do not. We note that a simple tunnel is not able to support Quick-Start.
クィック-開始を支持するトンネル: 私たちは、トンネル経路に沿ったルータがそれでクィック-スタートRequestを処理できるならIPトンネルが'クィック-開始を支持する'と言って、フィードバックします、クィック-スタートRequestの適切な可能な承認をもたらして。 いくつかのクィック-始めと互換性があるトンネルがクィック-開始を支持しますが、他のものはそうしません。 私たちは、簡単なトンネルがクィック-開始を支持できないことに注意します。
From a security point of view, the use of Quick-Start in the outer header of an IP tunnel might raise security concerns because an adversary could tamper with the Quick-Start information that propagates beyond the tunnel endpoint, or because the Quick-Start Option exposes information to network scanners. Our approach is to make supporting Quick-Start an option for IP tunnels. That is, in environments or tunneling protocols where the risks of using Quick- Start are judged to outweigh its benefits, the tunnel can simply delete the Quick-Start Option or zero the Quick-Start rate request and QS TTL fields before encapsulation. The result is that there are two viable options for IP tunnels to be compatible with Quick-Start. The first option is the simple tunnel described above and in Section 6.1, where the tunnel is compatible with Quick-Start but does not
セキュリティ観点から、敵がトンネル終点で伝播されるクィック-スタート情報をいじることができたか、またはクィック-スタートOptionがネットワークスキャナに情報を露出するので、IPトンネルの外側のヘッダーにおけるクィック-始めの使用は安全上の配慮を上げるかもしれません。 私たちのアプローチはサポートクィック-始めをIPトンネルのためのオプションにすることです。 トンネルは、すなわち、クィック始めを使用する危険が利益を重いと判断される環境かトンネリングプロトコルでは、単にクィック-スタートOptionを削除するか、またはカプセル化の前にクィック-スタートレート要求とQS TTL分野のゼロに合うことができます。 結果はIPトンネルがクィック-始めと互換性があるように2つの実行可能なオプションがあるということです。 第1の選択はセクションの上と、そして、トンネルがクィック-始めと互換性がありますが、するセクション6.1で説明された簡単なトンネルです。
Floyd, et al. Experimental [Page 32] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[32ページ]RFC4782クィックスタートとIP2007年1月
support Quick-Start, where all Quick-Start Requests along the path will be rejected. The second approach is a Quick-Start-capable mode, described in Section 6.3, where the tunnel actively supports Quick- Start.
クィック-開始を支持してください。そこでは、経路に沿ったすべてのクィック-スタートRequestsが拒絶されるでしょう。 2番目のアプローチはトンネルが活発にクィックStartを支持するセクション6.3で説明されたできるクィックStartモードです。
6.1. Simple Tunnels that Are Compatible with Quick-Start
6.1. 純真なTunnelsはクィック-始めがあるそのAre Compatibleです。
This section describes the ways that a simple tunnel can be compatible with Quick-Start but not support Quick-Start, resulting in the rejection of all Quick-Start Requests that traverse the tunnel.
このセクションは簡単なトンネルがクィック-始めと互換性がありますが、クィック-開始を支持できない方法を述べます、トンネルを横断するすべてのクィック-スタートRequestsの拒絶をもたらして。
If the tunnel ingress for the simple tunnel is at a router, the IP TTL of the inner header is generally decremented during forwarding before tunnel encapsulation takes place. In this case, TTL Diff will be changed, correctly causing the Quick-Start Request to be rejected. For a simple tunnel, it is preferable if the Quick-Start Request is not copied to the outer header, saving the routers within the tunnel from unnecessarily processing the Quick-Start Request. However, the Quick-Start Request will be rejected correctly in this case whether or not the Quick-Start Request is copied to the outer header.
ルータに簡単なトンネルへのトンネルイングレスがあるなら、トンネルカプセル化が行われる前に一般に、内側のヘッダーのIP TTLは推進の間、減少します。 この場合、クィック-スタートRequestが拒絶されることを正しく引き起こすと、TTL Diffを変えるでしょう。 簡単なトンネルに関しては、クィック-スタートRequestが外側のヘッダーにコピーされないなら、望ましいです、トンネルの中のルータが不必要にクィック-スタートRequestを処理するのを救って。 しかしながら、クィック-スタートRequestが外側のヘッダーにコピーされるか否かに関係なく、クィック-スタートRequestはこの場合正しく拒絶されるでしょう。
6.1.1. Simple Tunnels that Are Aware of Quick-Start
6.1.1. 純真なTunnelsはクィック-始めのそのAre Awareです。
If a tunnel ingress is aware of Quick-Start, but does not want to support Quick-Start, then the tunnel ingress MUST either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the inner header before encapsulation. Section 6.3 describes the procedures for a tunnel that does want to support Quick-Start.
トンネルイングレスがクィック-始めを意識していますが、クィック-開始を支持したくないなら、トンネルイングレスは、クィック-スタートレート要求、QS TTL、およびQS Nonce分野のゼロを合わせなければならないか、またはカプセル化の前に内側のヘッダーからクィック-スタートOptionを取り外さなければなりません。 セクション6.3はクィック-開始を支持したがっているトンネルに手順について説明します。
Deleting the Quick-Start Option or zeroing the Quick-Start rate request *after decapsulation* also serves to prevent the propagation of Quick-Start information, and is compatible with Quick-Start. If the outer header does not contain a Quick-Start Request, a Quick- Start-aware tunnel egress MUST reject the inner Quick-Start Request by zeroing the Rate Request field in the inner header, or by deleting the Quick-Start Option.
クィック-スタートOptionを削除するか、または被膜剥離術*の後にクィック-スタートレート要求*のゼロをまた合わせるのも、クィック-スタート情報の伝播を防ぐのに役立って、クィック-始めと互換性があります。 外側のヘッダーがクィック-スタートRequestを含んでいないなら、クィックのスタート意識しているトンネル出口は、内側のヘッダーのRate Request分野のゼロを合わせるか、またはクィック-スタートOptionを削除することによって、内側のクィック-スタートRequestを拒絶しなければなりません。
If the tunnel ingress is at a sending host or router where the IP TTL is not decremented prior to encapsulation, and neither tunnel endpoint is aware of Quick-Start, then this allows false positives, described in the section below.
送付ホストかルータにはトンネルイングレスがIP TTLがカプセル化の前に減少しないところにあって、どちらのトンネル終点もクィック-始めを意識していないなら、これは下のセクションで説明された無病誤診を許容します。
Floyd, et al. Experimental [Page 33] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[33ページ]RFC4782クィックスタートとIP2007年1月
6.2. Simple Tunnels that Are Not Compatible with Quick-Start
6.2. 純真なTunnelsはクィック-始めがあるそのAre Not Compatibleです。
Sometimes a tunnel implementation that does not support Quick-Start is independent of the TCP sender or a router implementation that supports Quick-Start. In these cases, it is possible that a Quick- Start Request gets erroneously approved without the routers in the tunnel having individually approved the request, causing a false positive.
時々、クィック-開始を支持しないトンネル実現はクィック-開始を支持するTCP送付者かルータ実現から独立しています。 これらの場合では、個別に要求を承認して、クィックスタートRequestがトンネルでルータなしで誤って承認されるのは、可能です、無病誤診を引き起こして。
If a tunnel ingress is a separate component from the TCP sender or IP forwarding, it is possible that a packet with a Quick-Start option is encapsulated without the IP TTL being decremented first, or with both IP TTL and QS TTL being decremented before the tunnel encapsulation takes place. If the tunnel ingress does not know about Quick-Start, a valid Quick-Start Request with unchanged TTL Diff traverses in the inner header, while the outer header most likely does not carry a Quick-Start Request. If the tunnel egress also does not support Quick-Start, it remains possible that the Quick-Start Request would be falsely approved, because the packet is decapsulated using the Quick-Start Request from the inner header, and the value of TTL Diff echoed to the sender remains unchanged. For example, such a scenario can occur with a Bump-In-The-Stack (BITS), an IPsec encryption implementation where the data encryption occurs between the network drivers and the TCP/IP protocol stack [RFC4301].
トンネルイングレスがTCP送付者かIP推進からの別々のコンポーネントであるなら、最初に減少するIP TTLなしでトンネルカプセル化が行われる前にIP TTLとQS TTLの両方が減少している状態でクィック-スタートオプションがあるパケットがカプセルに入れられるのは、可能です。 トンネルイングレスがクィック-始めに関して知らないなら、外側のヘッダーがたぶんクィック-スタートRequestを運ばない間の変わりのないTTL Diff横断が内側のヘッダーにある状態で、クィック-スタートRequestです有効な。 トンネル出口もクィック-開始を支持しないなら、クィック-スタートRequestが間違って承認されるだろうというのは可能なままで残っています、パケットが内側のヘッダーからクィック-スタートRequestを使用することでdecapsulatedされて、送付者に反響されたTTL Diffの値は変わりがないので。 例えば、そのようなシナリオはスタックのBump(BITS)、IPsec暗号化実現データ暗号化がネットワークドライバーの間にどこに起こるか、そして、TCP/IPプロトコル・スタック[RFC4301]で起こることができます。
As one example, if a remote access VPN client uses a BITS structure, then Quick-Start obstacles between the client and the VPN gateway won't be seen. This is a particular problem because the path between the client and the VPN gateway is likely to contain the most congested part of the path. Because most VPN clients are reported to use BITS [H05], we will explore this in more detail.
1つの例として、遠隔アクセスのVPNクライアントがBITS構造を使用すると、クライアントとVPNゲートウェイの間のクィック-スタート障害は見られないでしょう。 クライアントとVPNゲートウェイの間の経路が経路の最も混雑している地域を含みそうであるので、これは特定の問題です。 ほとんどのVPNクライアントがBITS[H05]を使用すると報告されるので、私たちはさらに詳細にこれを探検するつもりです。
A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where the encryption occurs on an outboard processor, offloading the encryption processing overhead from the host or router [RFC4301]. The BITW device is usually IP addressable, which means that the IP TTL is decremented before the packet is passed to the BITW. If the QS TTL is not decremented, then the value of TTL Diff is changed, and the Quick-Start Request will be denied. However, if the BITW supports a host and does not have its own IP address, then the IP TTL is not decremented before the packet is passed from the host to the BITW, and a false positive could occur.
ワイヤのBump(BITW)は暗号化が船外のプロセッサの上に起こるところのIPsec暗号化実現です、ホストかルータ[RFC4301]から暗号化処理オーバヘッドを積み下ろして。 通常、BITW装置はアドレス可能なIPです。(そのIPはパケットがBITWに通過される前にIP TTLが減少することを意味します)。 QS TTLを減少させないなら、TTL Diffの値を変えます、そして、クィック-スタートRequestを否定するでしょう。 しかしながら、BITWがホストを支持して、それ自身のIP住所を知っていないなら、パケットがホストからBITWまで通過される前にIP TTLは減少しませんでした、そして、無病誤診は起こることができました。
Other tunnels that need to be looked at are IP tunnels over non- network protocols, such as IP over TCP and IP over UDP [RFC3948], and tunnels using the Layer Two Tunneling Protocol [RFC2661].
見られる必要がある他のトンネルは非ネットワーク・プロトコルの上のIPトンネルです、TCPの上のIPとUDP[RFC3948]の上のIPや、Layer Two Tunnelingプロトコルを使用するトンネルなどのように[RFC2661]。
Floyd, et al. Experimental [Page 34] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[34ページ]RFC4782クィックスタートとIP2007年1月
Section 9.2 discusses the related issue of non-IP queues, such as layer-two Ethernet or ATM (Asynchronous Transfer Mode) networks, as another instance of possible bottlenecks that do not participate in the Quick-Start feedback.
セクション9.2は非IP待ち行列の関連する問題について論じます、層-2つのイーサネットやATM(非同期なTransfer Mode)ネットワークのように、クィック-スタートフィードバックに参加しない可能なボトルネックの別の例として。
6.3. Tunnels That Support Quick-Start
6.3. クィックスタートを支持するトンネル
This section discusses tunnels configured to support Quick-Start.
このセクションはクィック-開始を支持するために構成されたトンネルについて論じます。
If the tunnel ingress node chooses to locally approve the Quick- Start Request, then the ingress node MUST decrement the Quick-Start TTL at the same time it decrements the IP TTL, and MUST copy IP TTL and the Quick-Start Option from the inner IP header to the outer header. During encapsulation, the tunnel ingress MUST zero the Quick-Start rate request field in the inner header to ensure that the Quick-Start Request will be rejected if the tunnel egress does not support Quick-Start.
トンネルイングレスノードが、局所的にクィックスタートRequestを承認するのを選ぶなら、イングレスノードは、それがIP TTLを減少させる同時代にクィック-スタートTTLを減少させなければならなくて、内側のIPヘッダーから外側のヘッダーまでIP TTLとクィック-スタートOptionをコピーしなければなりません。 カプセル化の間、トンネルイングレスは、トンネル出口がクィック-開始を支持しないとクィック-スタートRequestが拒絶されるのを保証するために内側のヘッダーのクィック-スタートレート要求分野のゼロに合わなければなりません。
If the tunnel ingress node does not choose to locally approve the Quick-Start Request, then it MUST either delete the Quick-Start option from the inner header before encapsulation, or zero the QS TTL and the Rate Request fields before encapsulation.
トンネルイングレスノードが、局所的にクィック-スタートRequestを承認するのを選ばないなら、カプセル化の前に内側のヘッダーからクィック-スタートオプションを削除しなければならないか、またはQS TTLのゼロを合わせなければなりません、そして、Rate Requestは以前、カプセル化をさばきます。
Upon decapsulation, if the outer header contains a Quick-Start option, the tunnel egress MUST copy the IP TTL and the Quick-Start option from the outer IP header to the inner header.
被膜剥離術では、外側のヘッダーがクィック-スタートオプションを含んでいるなら、トンネル出口はIP TTLと外側のIPヘッダーから内側のヘッダーまでのクィック-スタートオプションをコピーしなければなりません。
IPsec uses the IKE (Internet Key Exchange) Protocol for security associations. We do not consider the interactions between Quick- Start and IPsec with IKEv1 [RFC2409] in this document. Now that the RFC for IKEv2 [RFC4306] is published, we plan to specify a modification of IPsec to allow the support of Quick-Start to be negotiated; this modification will specify the negotiation between tunnel endpoints to allow or forbid support for Quick-Start within the tunnel. This was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section 9.2]. This negotiation of Quick-Start capability in an IPsec tunnel will be specified in a separate IPsec document. This document will also include a discussion of the potential effects of an adversary's modifications of the Quick-Start field (as in Sections 18 and 19 of RFC 3168), and of the security considerations of exposing the Quick-Start rate request to network scanners.
IPsecはセキュリティ協会にIKE(インターネット・キー・エクスチェンジ)プロトコルを使用します。 私たちは本書ではIKEv1[RFC2409]とクィック始めとIPsecとの相互作用を考えません。 IKEv2[RFC4306]のためのRFCが発行されるので、私たちは、クィック-始めのサポートが交渉されるのを許容するためにIPsecの変更を指定するのを計画しています。 この変更は、トンネルの中のクィック-始めのサポートを許容するか、または禁じるためにトンネル終点の間の交渉を指定するでしょう。 電子証券取引ネットワークのためにIKEv1[RFC3168、セクション9.2]と共にIPsecトンネルにこれをしました。 IPsecトンネルでのクィック-スタート能力のこの交渉は別々のIPsecドキュメントで指定されるでしょう。 また、このドキュメントは敵のクィック-スタート分野(RFC3168のセクション18と19のように)の変更の潜在的効果、およびクィック-スタートレート要求をネットワークスキャナに露出するセキュリティ問題の議論を含むでしょう。
6.4. Quick-Start and MPLS
6.4. クィックスタートとMPLS
The behavior of Quick-Start with MPLS is similar to the behavior of Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL is decremented as part of traversing the MPLS path, these paths are compatible with Quick-Start, but do not support Quick-Start; Quick-
MPLSとのクィック-始めの振舞いはIP Tunnelsとのクィック-始めの振舞いと同様です。 IP TTLがMPLS経路を横断する一部として減少するそれらのMPLS経路において、これらの経路はクィック-始めと互換性がありますが、クィック-開始を支持しないでください。 迅速
Floyd, et al. Experimental [Page 35] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[35ページ]RFC4782クィックスタートとIP2007年1月
Start Requests that are traversing these paths will be correctly understood by the transport sender as having been denied. Any MPLS paths where the IP TTL is not decremented as part of traversing the MPLS path would be not compatible with Quick-Start; such paths would result in false positives, where the TCP sender incorrectly believes that the Quick-Start Request was approved by all routers along the path.
これらの経路を横断しているスタートRequestsが否定されたと正しく輸送送付者に解釈されるでしょう。 IP TTLがMPLS経路を横断する一部として減少しないどんなMPLS経路もクィック-始めと互換性がないでしょう。 そのような経路は無病誤診をもたらすでしょう。そこでは、TCP送付者が、クィック-スタートRequestが経路に沿ったすべてのルータによって承認されたと不当に信じています。
For cases where the ingress node to the MPLS path is aware of Quick- Start, this node should either zero the Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the Quick-Start Option from the IP header.
MPLS経路へのイングレスノードがクィック始めを意識しているケースのために、このノードは、クィック-スタートレート要求、QS TTL、およびQS Nonce分野のゼロを合わせるはずであるか、またはIPヘッダーからクィック-スタートOptionを取り外すはずです。
7. The Quick-Start Mechanism in Other Transport Protocols
7. 他のトランスポート・プロトコルのクィックスタートメカニズム
The section earlier specified the use of Quick-Start in TCP. In this section, we generalize this to give guidelines for the use of Quick- Start with other transport protocols. We also discuss briefly how Quick-Start could be specified for other transport protocols.
セクションは前にTCPにおけるクィック-始めの使用を指定しました。 このセクションでは、私たちは、他のトランスポート・プロトコルによるクィック始めの使用のためのガイドラインを与えるためにこれを一般化します。 また、私たちは簡潔にどうクィック-始めを他のトランスポート・プロトコルに指定できたかについて議論します。
The general guidelines for Quick-Start in transport protocols are as follows:
トランスポート・プロトコルにおけるクィック-始めのための一般的ガイドラインは以下の通りです:
* Quick-Start is only specified for unicast transport protocols with
appropriate congestion control mechanisms. Note: Quick-Start is
not a replacement for standard congestion control techniques, but
meant to augment their operation.
* 迅速な始めは適切な混雑制御機構注意でユニキャストトランスポート・プロトコルに指定されるだけです: 迅速な始めは、標準の混雑制御方法との交換ではありませんが、彼らの操作を増大させることを意味しました。
* A transport-level mechanism is needed for the Quick-Start Response
from the receiver to the sender. This response contains the Rate
Request, TTL Diff, and QS Nonce.
* 輸送レベルメカニズムが受信機から送付者までのクィック-スタートResponseに必要です。 この応答はRate Request、TTL Diff、およびQS Nonceを含んでいます。
* The sender checks the validity of the Quick-Start Response.
* 送付者はクィック-スタートResponseの正当性をチェックします。
* The sender has an estimate of the round-trip time, and translates
the Quick-Start Response into an allowed window or allowed sending
rate. The sender sends a Report of the Approved Rate. The sender
starts sending Quick-Start packets, rate-paced out at the approved
sending rate.
* 送付者は、往復の現代の見積りを持って、許容窓か許容送付レートにクィック-スタートResponseを移します。 送付者はApproved RateのReportを送ります。 送付者はクィック-スタートパケット、承認された発信にレートで歩調を合わせられたレートを送り始めます。
* After the sender receives the first acknowledgement packet for a
Quick-Start packet, no more Quick-Start packets are sent. The
sender adjusts its current congestion window or sending rate to be
consistent with the actual amount of data that was transmitted in
that round-trip time.
* 送付者がクィック-スタートパケットのために最初の確認応答パケットを受けた後に、それ以上のクィック-スタートパケットを全く送りません。 送付者は、その往復の時間で伝えられた実際のデータ量と一致しているようにその現在の混雑ウィンドウか送付レートを調整します。
Floyd, et al. Experimental [Page 36] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[36ページ]RFC4782クィックスタートとIP2007年1月
* When the last Quick-Start packet is acknowledged, the sender
continues using the standard congestion control mechanisms of that
protocol.
* 最後のクィック-スタートパケットが承認されるとき、送付者は、そのプロトコルの標準の混雑制御機構を使用し続けています。
* If one of the Quick-Start packets is lost, then the sender reverts
to the standard congestion control method of that protocol that
would have been used if the Quick-Start Request had not been
approved. In addition, the sender takes into account the
information that the Quick-Start congestion window was too large
(e.g., by decreasing ssthresh in TCP).
* クィック-スタートパケットの1つが無くなるなら、送付者はクィック-スタートRequestが承認されなかったなら使用されたそのプロトコルの標準の輻輳制御方法に先祖帰りをします。 さらに、送付者はクィック-スタート混雑ウィンドウが大き過ぎたという(例えば、TCPでssthreshを減少させるのによる)情報を考慮に入れます。
8. Using Quick-Start
8. クィックスタートを使用します。
8.1. Determining the Rate to Request
8.1. レートを要求する測定すること。
As discussed in [SAF06], the data sender does not necessarily have information about the size of the data transfer at connection initiation; for example, in request-response protocols such as HTTP, the server doesn't know the size or name of the requested object during connection initiation. [SAF06] explores some of the performance implications of overly large Quick-Start Requests, and discusses heuristics that end-nodes could use to size their requests appropriately. For example, the sender might have information about the bandwidth of the last-mile hop, the size of the local socket buffer, or of the TCP receive window, and could use this information in determining the rate to request. Web servers that mostly have small objects to transfer might decide not to use Quick-Start at all, since Quick-Start would be of little benefit to them.
[SAF06]で議論するように、データ送付者は必ず接続開始にデータ転送のサイズの情報を持っているというわけではありません。 例えば、HTTPなどの要求応答プロトコルで、サーバは接続開始の間、要求された物のサイズか名前を知りません。 [SAF06]は、ひどく大きいクィック-スタートRequestsの性能含意のいくつかを探って、発見的教授法について議論します。エンドノードは適切に彼らの要求をサイズまで使用するかもしれません。 例えば、送付者は、最後のマイルホップの帯域幅、ローカルのソケットバッファのサイズの情報を持っているか、またはTCPについて窓を受け取るかもしれなくて、レートを測定する際にこの情報を要求に使用できました。 移す小さい物をほとんど持っているウェブサーバーは、全くクィック-始めを使用しないと決めるかもしれません、クィック-始めはそれらにおいて利益とほとんどならないでしょう、したがって。
Quick-Start will be more effective if Quick-Start Requests are not larger than necessary; every Quick-Start Request that is approved but not used (or not fully used) takes away from the bandwidth pool available for granting successive Quick-Start Requests.
クィック-スタートRequestsが必要とするほど大きくないなら、迅速な始めは、より効果的になるでしょう。 承認されますが、使用されるというわけではない(または、完全に使用されるというわけではありません)あらゆるクィック-スタートRequestが連続したクィック-スタートRequestsを与えるのに利用可能な帯域幅プールから遠くで取ります。
8.2. Deciding the Permitted Rate Request at a Router
8.2. ルータで受入れられたレート要求について決めます。
In this section, we briefly outline how a router might decide whether or not to approve a Quick-Start Request. The router should ask the following questions:
このセクションで、ルータが、クィック-スタートRequestを承認するかどうかどう決めるかもしれないかを私たちは簡潔に概説します。 ルータは以下の質問をするべきです:
* Has the router's output link been underutilized for some time
(e.g., several seconds)?
* ルータの出力リンクはしばらく(例えば数秒)underutilizedされていますか?
* Would the output link remain underutilized if the arrival rate were
to increase by the aggregate rate requests that the router has
approved over the last fraction of a second?
* 出力リンクは到着率がルータが1秒の最後の何分の一の上承認したという集合レート要求で増加することであったならunderutilizedされたままで残っているでしょうか?
Floyd, et al. Experimental [Page 37] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[37ページ]RFC4782クィックスタートとIP2007年1月
In order to answer the last question, the router must have some knowledge of the available bandwidth on the output link and of the Quick-Start bandwidth that could arrive due to recently approved Quick-Start Requests. In this way, if an underutilized router experiences a flood of Quick-Start Requests, the router can begin to deny Quick-Start Requests while the output link is still underutilized.
最後の質問に答えるために、ルータには最近承認されたクィック-スタートRequestsのため到着できる出力リンクにおける利用可能な帯域幅とクィック-スタート帯域幅に関する何らかの知識がなければなりません。 このように、underutilizedルータがクィック-スタートRequestsの洪水になるなら、出力リンクがまだunderutilizedされている間、ルータはクィック-スタートRequestsを否定し始めることができます。
A simple way for the router to keep track of the potential bandwidth from recently approved requests is to maintain two counters: one for the total aggregate Rate Requests that have been approved in the current time interval [T1, T2], and one for the total aggregate Rate Requests approved over a previous time interval [T0, T1]. However, this document doesn't specify router algorithms for approving Quick- Start Requests, or make requirements for the appropriate time intervals for remembering the aggregate approved Quick-Start bandwidth. A possible router algorithm is given in Appendix E, and more discussion of these issues is available in [SAF06].
ルータが最近承認された要求からの潜在的帯域幅の動向をおさえる簡単な方法は2台のカウンタを維持することです: 現在の時間間隔[T1、T2]で承認された総集合Rate Requestsのためのもの、および前回間隔[T0、T1]の間に承認された総集合Rate Requestsのためのもの。 しかしながら、このドキュメントは、承認しているクィックスタートRequestsにルータアルゴリズムを指定もしませんし、また集合承認されたクィック-始めを覚えているための適切な時期間隔の間の要件を帯域幅にしません。 Appendix Eで可能なルータアルゴリズムを与えます、そして、これらの問題の、より多くの議論が[SAF06]で利用可能です。
* If the router's output link has been underutilized and the
aggregate of the Quick-Start Request Rate options granted is low
enough to prevent a near-term bandwidth shortage, then the router
could approve the Quick-Start Request.
* ルータの出力リンクがunderutilizedされて、Request Rateオプションが承諾したクィック-始めの集合が短期間帯域幅不足を防ぐことができるくらい低いなら、ルータはクィック-スタートRequestを承認するかもしれません。
Section 10.2 discusses some of the implementation issues in processing Quick-Start Requests at routers. [SAF06] discusses the range of possible Quick-Start algorithms at the router for deciding whether to approve a Quick-Start Request. In order to explore the limits of the possible functionality at routers, [SAF06] also discusses Extreme Quick-Start mechanisms at routers, where the router would keep per-flow state concerning approved Quick-Start requests.
セクション10.2はルータで処理クィック-スタートRequestsの導入問題のいくつかについて論じます。 [SAF06]は、クィック-スタートRequestを承認するかどうか決めるためにルータで可能なクィック-スタートアルゴリズムの範囲について議論します。 また、ルータにおける可能な機能性の限界について調査するために、[SAF06]はルータにおけるExtremeクィック-スタートメカニズムについて議論します。そこでは、ルータが承認されたクィック-スタート要求に関して1流れあたりの状態を維持するでしょう。
9. Evaluation of Quick-Start
9. クィックスタートの評価
9.1. Benefits of Quick-Start
9.1. クィックスタートの利益
The main benefit of Quick-Start is the faster start-up for the transport connection itself. For a small TCP transfer of one to five packets, Quick-Start is probably of very little benefit; at best, it might shorten the connection lifetime from three to two round-trip times (including the round-trip time for connection establishment). Similarly, for a very large transfer, where the slow-start phase would have been only a small fraction of the connection lifetime, Quick-Start would be of limited benefit. Quick-Start would not significantly shorten the connection lifetime, but it might eliminate or at least shorten the start-up phase. However, for moderate-sized connections in a well-provisioned environment, Quick-Start could possibly allow the entire transfer of M packets to be completed in
クィック-始めの主な恩恵は輸送接続自体のための、より速い始動です。 1〜5つのパケットの小さいTCP転送のために、クィック-始めはたぶん非常に少ない利益のものです。 せいぜい、それは往復の3〜2回(コネクション確立のための往復の時間を含んでいる)までのコネクション存続期間を短くするかもしれません。 同様に、非常に大きい転送のために、クィック-始めは遅れた出発フェーズがコネクション存続期間のわずかな部分にすぎなかっただろうことの限られた利益のものでしょう。 迅速な始めがコネクション存続期間をかなり短くしないでしょうが、それは、始動フェーズを排除するか、または少なくとも、短くするかもしれません。 しかしながら、よく食糧を供給された環境における中道主義者サイズの接続のために、クィック-始めはMの全体の転送に完成されるパケットを許容するかもしれません。
Floyd, et al. Experimental [Page 38] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[38ページ]RFC4782クィックスタートとIP2007年1月
one round-trip time (after the initial round-trip time for the SYN exchange), instead of the log_2(M)-2 round-trip times that it would normally take for the data transfer, in an uncongested environments (assuming an initial window of four packets).
通常、そうするだろうというログ_2(M)-2の往復の回の代わりに往復の1回(SYN交換のための初期の往復の時間の後の)、非充血している環境におけるデータ転送に取ってください(4つのパケットの初期の窓を仮定して)。
9.2. Costs of Quick-Start
9.2. クィックスタートのコスト
This section discusses the costs of Quick-Start for the connection and for the routers along the path.
このセクションは接続とルータのための経路に沿ったクィック-始めのコストについて論じます。
The cost of having a Quick-Start Request packet dropped: Measurement studies cited earlier [MAF04] suggest that on a wide range of paths in the Internet, TCP SYN packets containing unknown IP options will be dropped. Thus, for the sender one risk in using Quick-Start is that the packet carrying the Quick-Start Request could be dropped in the network. It is particularly costly to the sender when a TCP SYN packet is dropped, because in this case the sender should wait for an RTO of three seconds before re-sending the SYN packet, as specified in Section 4.7.2.
クィック-スタートRequestパケットを持つ費用は低下しました: より早く引用された測定研究[MAF04]は、インターネットのさまざまな経路では、未知のIPオプションを含むTCP SYNパケットが落とされるのを示します。 したがって、送付者1にとって、クィック-始めを使用することにおけるリスクはネットワークでクィック-スタートRequestを運ぶパケットを落とすことができたということです。 TCP SYNパケットが落とされるとき、送付者には、それは特に高価です、SYNパケットを再送する前に送付者がこの場合3秒のRTOを待つべきであるので、セクション4.7.2で指定されるように。
The cost of having a Quick-Start data packet dropped: Another risk for the sender in using Quick-Start lies in the possibility of suffering from congestion-related losses of the Quick-Start data packets. This should be an unlikely situation because routers are expected to approve Quick-Start Requests only when they are significantly underutilized. However, a transient increase in cross-traffic in one of the routers, a sudden decrease in available bandwidth on one of the links, or congestion at a non-IP queue could result in packet losses even when the Quick-Start Request was approved by all of the routers along the path. If a Quick-Start packet is dropped, then the sender reverts to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved, so the performance cost to the connection of having a Quick-Start packet dropped is small, compared to the performance without Quick-Start. (On the other hand, the performance difference between Quick-Start with a Quick-Start packet dropped and Quick- Start with no Quick-Start packet dropped can be considerable.)
クィック-スタートデータ・パケットを持つ費用は低下しました: クィック-始めを使用することにおける送付者のための別の危険がクィック-スタートデータ・パケットの混雑関連の損失に苦しむ可能性にあります。 彼らがかなりunderutilizedされるときだけ、ルータがクィック-スタートRequestsを承認すると予想されるので、これは思いも寄らない事態であるべきです。 しかしながら、クィック-スタートRequestは経路に沿ってすべてによってルータを承認さえされたとき、ルータの1つにおける交差交通の一過性増加、リンクの1つにおける利用可能な帯域幅での急減、または非IP待ち行列における混雑がパケット損失をもたらすかもしれません。 クィック-スタートパケットが落とされて、クィック-スタートRequestが承認されていなかったなら送付者がそれが使用した混雑制御機構に先祖帰りをするので、クィック-スタートパケットが落とされる接続への性能費用はわずかです、クィック-始めなしで性能と比べて。 (他方では、クィック-スタートパケットが落とされているクィック-始めとクィック-スタートパケットが全く落とされていないクィック始めの性能差は無視できない場合があります。)
Added complexity at routers: The main cost of Quick-Start at routers concerns the costs of added complexity. The added complexity at the end-points is moderate, and might easily be outweighed by the benefit of Quick-Start to the end hosts. The added complexity at the routers is also somewhat moderate; it involves estimating the unused bandwidth on the output link over the last several seconds, processing the Quick-Start request, and keeping a counter of the aggregate Quick-Start rate approved over the last fraction of a second. However, this added complexity at routers adds to the development cycle, and could
ルータにおける加えられた複雑さ: ルータにおけるクィック-始めの主な費用は加えられた複雑さのコストに関係があります。 エンドポイントにおける加えられた複雑さは、適度であり、容易に終わりのホストへのクィック-始めの恩恵より軽いかもしれません。 また、ルータにおける加えられた複雑さもいくらか適度です。 それは、出力リンクにおける未使用の帯域幅を最後の数秒の上見積もっていることを伴います、クィック-スタート要求を処理して、集合クィック-スタート率のカウンタを1秒の最後の何分の一の上承認し続けて。 そしてであることができましたしかしながら、これが、ルータにおける複雑さが開発サイクルに加えると言い足した。
Floyd, et al. Experimental [Page 39] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[39ページ]RFC4782クィックスタートとIP2007年1月
prevent the addition of other competing functionality to routers. Thus, careful thought would have to be given to the addition of Quick-Start to IP.
他の競争している機能性のルータへの添加を防いでください。 したがって、クィック-始めのIPへの追加に考慮を与えなければならないでしょう。
The slow path in routers: Another drawback of Quick-Start is that packets containing the Quick-Start Request message might not take the fast path in routers, particularly in the beginning of Quick-Start's deployment in the Internet. This would mean some extra delay for the end hosts, and extra processing burden for the routers. However, as discussed in Sections 4.1 and 4.7, not all packets would carry the Quick-Start option. In addition, for the underutilized links where Quick-Start Requests could actually be approved, or in typical environments where most of the packets belong to large flows, the burden of the Quick- Start Option on routers would be considerably reduced. Nevertheless, it is still conceivable, in the worst case, that many packets would carry Quick-Start Requests; this could slow down the processing of Quick-Start packets in routers considerably. As discussed in Section 9.6, routers can easily protect against this by enforcing a limit on the rate at which Quick-Start Requests will be considered. [RW03] and [RW04] contain measurements of the impact of IP Option Processing on packet round-trip times.
ルータにおける遅い経路: クィック-始めの別の欠点はクィック-スタートRequestメッセージを含むパケットがルータにおける高速経路を取らないかもしれないということです、特にインターネットでのクィック-始めの展開の始めに。 これは、終わりのホストのために何らかの余分な遅れを意味して、ルータのために余分な処理負担を意味するでしょう。 しかしながら、セクション4.1と4.7で議論するように、すべてのパケットがクィック-スタートオプションを運ぶというわけではないでしょう。 さらに、実際にクィック-スタートRequestsを承認できたunderutilizedリンク、またはパケットの大部分が大きい流れに属す典型的な環境で、ルータのクィックスタートOptionの負担はかなり減少するでしょう。 それにもかかわらず、多くのパケットがクィック-スタートRequestsを運ぶだろうというのがまだ最悪の場合には想像できます。 これはルータにおける、クィック-スタートパケットの処理をかなり減速させるかもしれません。 セクション9.6で議論するように、ルータは限界にクィック-スタートRequestsが考えられるレートに押しつけることによって、容易にこれから守ることができます。 [RW03]と[RW04]はパケットの往復の回にIP Option Processingの衝撃の測定値を含んでいます。
Multiple paths:
複数の経路:
One limitation of Quick-Start is that it presumes that the data packets of a connection will follow the same path as the Quick-Start request packet. If this is not the case, then the connection could be sending the Quick-Start packets, at the approved rate, along a path that was already congested, or that became congested as a result of this connection. Thus, Quick-Start could give poor performance when there is a routing change immediately after the Quick-Start Request is approved, and the Quick-Start data packets follow a different path from that of the original Quick-Start Request. This is, however, similar to what would happen for a connection with sufficient data, if the connection's path was changed in the middle of the connection, which had already established the allowed initial rate.
クィック-始めの1つの制限は接続のデータ・パケットがクィック-スタートリクエスト・パケットと同じ経路に続くと推定するということです。 これがそうでないなら、接続はクィック-スタートパケットを送るかもしれません、承認されたレートで、既に充血したか、またはこの接続の結果、混雑するようになった経路に沿って。 したがって、クィック-スタートRequestが承認されている直後ルーティング変化があって、クィック-スタートデータ・パケットがオリジナルのクィック-スタートRequestのものから異なる道を歩むと、クィック-始めは不十分な性能を与えるかもしれません。 しかしながら、これは十分なデータとの関係のために起こることと同様です、既に許容初期のレートを確立した接続の途中で接続の経路を変えたなら。
As specified in Section 3.3, a router that uses multipath routing for packets within a single connection must not approve a Quick-Start Request. Quick-Start would not perform robustly in an environment with multipath routing, where different packets in a connection routinely follow different paths. In such an environment, the Quick-Start Request and some fraction of the packets in the connection might take an underutilized path, while the rest of the packets take an alternate, congested path.
セクション3.3で指定されるように、パケットに単独結合の中で多重通路ルーティングを使用するルータはクィック-スタートRequestを承認してはいけません。 迅速な始めは環境で多重通路ルーティングで強壮に働かないでしょう。そこでは、接続における異なったパケットがきまりきって異なった経路に続きます。 そのような環境で、クィック-スタートRequestと接続におけるパケットのある部分がunderutilized経路を取るかもしれません、パケットの残りは交互の、そして、混雑している経路を取りますが。
Floyd, et al. Experimental [Page 40] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[40ページ]RFC4782クィックスタートとIP2007年1月
Non-IP queues: A problem of any mechanism for feedback from routers at the IP level is that there can be queues and bottlenecks in the end-to-end path that are not in IP-level routers. As an example, these include queues in layer-two Ethernet or ATM networks. One possibility would be that an IP-level router adjacent to such a non-IP queue or bottleneck would be configured to reject Quick-Start Requests if that was appropriate. One would hope that, in general, IP networks are configured so that non-IP queues between IP routers do not end up being the congested bottlenecks.
非IPは列を作ります: IPレベルにおけるルータからのフィードバックのためのどんなメカニズムの問題も、待ち行列があることができるということであり、IP-レベルルータにはない終わらせる終わりの経路を妨害します。 例として、これらは層-2つのイーサネットかATMネットワークに待ち行列を含んでいます。 1つの可能性はそれが適切であるならそのような非IP待ち行列かボトルネックに隣接したIP-レベルルータがクィック-スタートRequestsを拒絶するために構成されるだろうということでしょう。 人は、一般に、IPネットワークが構成されることを望んでいるでしょう、したがって、結局、IPルータの間の非IP待ち行列が混雑しているボトルネックではありません。
9.3. Quick-Start with QoS-Enabled Traffic
9.3. QoSによって可能にされた交通に伴うクィックスタート
The discussion in this document has largely been of Quick-Start with default, best-effort traffic. However, Quick-Start could also be used by traffic using some form of differentiated services, and routers could take the traffic class into account when deciding whether or not to grant the Quick-Start Request. We don't address this context further in this paper, since it is orthogonal to the specification of Quick-Start.
デフォルト、ベストエフォート型交通で議論は主に本書ではクィック-始めのものです。 しかしながら、また、何らかの形式の微分されたサービスを利用しながら、交通でクィック-始めを使用できるでしょう、そして、クィック-スタートRequestを与えるかどうか決めるとき、ルータは交通のクラスを考慮に入れるかもしれません。 それがクィック-始めの仕様と直交しているので、私たちはこの紙で、より詳しくこの文脈を記述しません。
Routers are also free to take into account their own priority classifications in processing Quick-Start Requests.
また、ルータは処理クィック-スタートRequestsで自由にそれら自身の優先権分類を考慮に入れることができます。
9.4. Protection against Misbehaving Nodes
9.4. ふらちな事するノードに対する保護
In this section, we discuss the protection against senders, receivers, or colluding routers or middleboxes lying about the Quick-Start Request.
このセクションで、私たちはクィック-スタートRequestに関してある送付者、受信機、馴れ合っているルータまたはmiddleboxesに対する保護について議論します。
9.4.1. Misbehaving Senders
9.4.1. ふらちな事をしているSenders
A transport sender could try to transmit data at a higher rate than that approved in the Quick-Start Request. The network could use a traffic policer to protect against misbehaving senders that exceed the approved rate, for example, by dropping packets that exceed the allowed transmission rate. The required Report of Approved Rate allows traffic policers to check that the Report of Approved Rate does not exceed the Rate Request actually approved at that point in the network in the previous Quick-Start Request from that connection. The required Approved Rate report also allows traffic policers to check that the sender's sending rate does not exceed the rate in the Report of Approved Rate.
輸送送付者はクィック-スタートRequestで承認されたそれより高いレートでデータを送ろうとすることができました。 ネットワークは、例えば許容通信速度を超えているパケットを落とすことによって承認されたレートを超えているふらちな事をしている送付者から守るのに交通policerを使用できました。 Approved Rateの必要なReportはApproved RateのReportがその時実際にその接続から前のクィック-スタートRequestのネットワークで承認されたRate Requestを超えていないのを交通policersをチェックさせます。 また、必要なApproved Rateレポートで、交通policersは、送付者の送付レートがApproved RateのReportでレートを超えていないのをチェックできます。
If a router or receiver receives an Approved Rate report that is larger than the Rate Request in the Quick-Start Request approved for that sender for that connection in the previous round-trip time, then the router or receiver could deny future Quick-Start Requests from
ルータか受信機がクィック-スタートRequestにおけるRate Requestがそれのための次に、前の往復の時間、ルータまたは受信機での関係が将来のクィック-スタートRequestsを否定する場合があったその送付者のために承認したより大きいApproved Rateレポートを受け取るなら
Floyd, et al. Experimental [Page 41] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[41ページ]RFC4782クィックスタートとIP2007年1月
that sender, e.g., by deleting the Quick-Start Request from future packets from that sender. We note that routers are not required to use Approved Rate reports to check if senders are cheating; this is at the discretion of the router.
その送付者、例えば、その送付者からの将来のパケットからの削除するのによるクィック-スタートRequest。 私たちは、ルータが送付者が不正行為をしているかどうかチェックするのにApproved Rateレポートを使用するのに必要でないことに注意します。 ルータの裁量にはこれがあります。
If a router sees a Report of Approved Rate, and did not see an earlier Quick-Start Request, then either the sender could be cheating, or the connection's path could have changed since the Quick-Start Request was sent. In either case, the router could decide to deny future Quick-Start Requests for this connection. In particular, it is reasonable for the router to deny a Quick-Start request if either the sender is cheating, or if the connection path suffers from path changes or multipathing.
ルータがApproved RateのReportを見て、以前のクィック-スタートRequestは見ないなら、送付者が不正行為をすることができるでしょうにか、または接続の経路が、クィック-スタートRequestを送ったので、変化したかもしれません。 どちらの場合ではも、ルータは、この接続のために将来のクィック-スタートRequestsを否定すると決めるかもしれません。 送付者が不正行為をしているか、または経路が接続であるなら経路変化かmultipathingが欠点であるなら、ルータがクィック-スタート要求を否定するのは、特に、妥当です。
If a router approved a Quick-Start Request, but does not see a subsequent Approved Rate report, then there are several possibilities: (1) the request was denied and/or dropped downstream, and the sender did not send a Report of Approved Rate; (2) the request was approved, but the sender did not send a Report of Approved Rate; (3) the Approved Rate report was dropped in the network; or (4) the Approved Rate report took a different path from the Quick-Start Request. In any of these cases, the router would be justified in denying future Quick-Start Requests for this connection.
ルータがクィック-スタートRequestを承認しますが、その後のApproved Rateレポートを見ないなら、いくつかの可能性があります: (1) 要求は、川下に否定される、そして/または、落とされました、そして、送付者はApproved RateのReportを送りませんでした。 (2) 要求は承認されましたが、送付者はApproved RateのReportを送りませんでした。 (3) Approved Rateレポートはネットワークで落とされました。 (4) または、Approved Rateレポートはクィック-スタートRequestと異なった経路を取りました。 これらの場合のいずれではも、ルータはこの接続のために将来のクィック-スタートRequestsを否定する際に正当化されるでしょう。
In any of the cases mentioned in the three paragraphs above (i.e., an Approved Rate report that is larger than the Rate Request in the earlier Quick-Start Request, a Report of Approved Rate with no preceding Rate Request, or a Rate Request with no Report of Approved Rate), a traffic policer may assume that Quick-Start is not being used appropriately, or is being used in an unsuitable environment (e.g., with multiple paths), and take some corresponding action.
3つのパラグラフで(すなわち、以前のクィック-スタートRequest、Rate Requestに先行することのないApproved RateのReport、またはApproved RateのReportのないRate Requestでは、Rate Requestより大きいApproved Rateレポート)を超えて言及された場合のいずれではも、交通policerはクィック-始めが適切に使用されていないか、または不適当な環境の中古である存在(例えば、複数の経路で)であり、撮影が何らかの対応する動作であると仮定するかもしれません。
What are the incentives for a sender to cheat by over-sending after a Quick-Start Request? Assuming that the sender's interests are measured by a performance metric such as the completion time for its connections, sometimes it might be in the sender's interests to cheat, and sometimes it might not; in some cases, it could be difficult for the sender to judge whether it would be in its interests to cheat. The incentives for a sender to cheat by over- sending after a Quick-Start Request are not that different from the incentives for a sender to cheat by over-sending even in the absence of Quick-Start, with one difference: the use of Quick-Start could help a sender evade policing actions from policers in the network. The Report of Approved Rate is designed to address this and to make it harder for senders to use Quick-Start to `cover' their cheating.
送付者がクィック-スタートRequestの後に発信し過ぎることによって不正行為をする誘因は何ですか? 送付者の利益のためが接続のための完成時間などのようなメートル法の性能によって測定されると仮定する場合、だます送付者の利益のためには時々、それがあるかもしれません、そして、ないかもしれません。 いくつかの場合、送付者が、だます利益のためにはそれがあるかを判断するのは、難しいかもしれません。 クィック-始めがないときでさえ発信し過ぎることによってだます送付者にとって、送付者がクィック-スタートRequestの後に発信し過ぎることによって不正行為をする誘因は誘因とそれ程違っていません、1つの違いで: クィック-始めの使用は、送付者が、policersからネットワークで動作を取り締まるのを回避するのを助けるかもしれません。 Approved RateのReportは、これを記述して、送付者が彼らの不正行為することを'覆うこと'にクィック-始めを使用するのをより困難にするように設計されています。
Floyd, et al. Experimental [Page 42] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[42ページ]RFC4782クィックスタートとIP2007年1月
9.4.2. Receivers Lying about Whether the Request was Approved
9.4.2. Whether Requestの周りの受信機LyingはApprovedでした。
One form of misbehavior would be for the receiver to lie to the sender about whether the Quick-Start Request was approved, by falsely reporting the TTL Diff and QS Nonce. If a router that understands the Quick-Start Request denies the request by deleting the request or by zeroing the QS TTL and QS Nonce, then the receiver can "lie" about whether the request was approved only by successfully guessing the value of the TTL Diff and QS Nonce to report. The chance of the receiver successfully guessing the correct value for the TTL Diff is 1/256, and the chance of the receiver successfully guessing the QS nonce for a reported rate request of K is 1/(2K).
1つの形式の不正行為は送付者には受信機がクィック-スタートRequestが承認されたかどうかあるだろうことです、間違ってTTL DiffとQS Nonceを報告することによって。 クィック-スタートRequestを理解しているルータが要求を削除するか、またはQS TTLとQS Nonceのゼロを合わせることによって要求を否定するなら、受信機は単にTTL DiffとQS Nonceの値が報告すると首尾よく推測することによって要求が承認されたかどうか「横たわることができます」。 受信機がTTL Diffのために首尾よく正しい値を推測するという機会は1/256であり、受信機の機会はKの報告されたレート要求のためのQS一回だけが1/(2K)であると首尾よく推測することです。
However, if the Quick-Start Request is denied only by a non-Quick- Start-capable router, or by a router that is unable to zero the QS TTL and QS Nonce fields, then the receiver could lie about whether the Quick-Start Requests were approved by modifying the QS TTL in successive requests received from the same host. In particular, if the sender does not act on a Quick-Start Request, then the receiver could decrement the QS TTL by one in the next request received from that host before calculating the TTL Diff, and decrement the QS TTL by two in the following received request, until the sender acts on one of the Quick-Start Requests.
しかしながら、Requestがクィック-始めであるならaだけによって否定される、非、-クィック-スタートRequestsが同じホストから受け取られた連続した要求でQS TTLを変更することによって承認されたか否かに関係なく、aによるスタート迅速なできるルータかQS TTLのゼロに合うことができないルータとQS Nonce分野、次に受信機がころがっていることができました。 特に、送付者がクィック-スタートRequestに影響しないなら、受信機は、TTL Diffについて計算する前にそのホストから受け取られた次の要求でQS TTLを1つ減少させて、以下の受信された要求でQS TTLを2つ減少させるかもしれません、送付者がクィック-スタートRequestsの1つに影響するまで。
Unfortunately, if a router doesn't understand Quick-Start, then it is not possible for that router to take an active step such as zeroing the QS TTL and QS Nonce to deny a request. As a result, the QS TTL is not a fail-safe mechanism for preventing lying by receivers in the case of non-Quick-Start-capable routers.
残念ながら、ルータがクィック-始めを理解していないなら、そのルータが要求を否定するためにQS TTLとQS Nonceのゼロを合わせなどなどの活発な方法を採るのは、可能ではありません。 その結果、QS TTLは、できる非迅速なスタートルータの場合で受信機を停泊させるのを防ぐためのフェールセイフのメカニズムではありません。
What would be the incentives for a receiver to cheat in reporting on a Quick-Start Request, in the absence of a mechanism such as the QS Nonce? In some cases, cheating would be of clear benefit to the receiver, resulting in a faster completion time for the transfer. In other cases, where cheating would result in Quick-Start packets being dropped in the network, cheating might or might not improve the receiver's performance metric, depending on the details of that particular scenario.
受信機がQS Nonceなどのメカニズムがないときクィック-スタートRequestに関して報告する際に不正行為をする誘因は何でしょうか? いくつかの場合、不正行為することは受信機において明確な利益となるでしょう、転送のための、より速い完成時間でなって。 不正行為するのは、他の場合では、メートル法で向上するか、または受信機の性能を向上させないかもしれません、その特定のシナリオの詳細によって。(そこでは、不正行為するのがネットワークで落とされるクィック-スタートパケットをもたらすでしょう)。
9.4.3. Receivers Lying about the Approved Rate
9.4.3. 承認されたレートに関してある受信機
A second form of receiver misbehavior would be for the receiver to lie to the sender about the Rate Request for an approved Quick-Start Request, by increasing the value of the Rate Request field. However, the receiver doesn't necessarily know the Rate Request in the original Quick-Start Request sent by the sender, and a higher Rate Request reported by the receiver will only be considered valid by the sender if it is no higher than the Rate Request originally requested
2番目の形式の受信機不正行為は承認されたクィック-スタートRequestのためのRate Requestに関して送付者には受信機があるだろうことです、Rate Request分野の値を増加させることによって。 しかしながら、受信機は必ず送付者によって送られたオリジナルのクィック-スタートRequestでRate Requestを知っているというわけではありません、そして、それが元々要求されたRate Requestほど高くない場合にだけ、受信機によって報告されたより高いRate Requestは有効であると送付者によって考えられるでしょう。
Floyd, et al. Experimental [Page 43] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[43ページ]RFC4782クィックスタートとIP2007年1月
by the sender. For example, if the sender sends a Quick-Start Request with a Rate Request of X, and the receiver reports receiving a Quick-Start Request with a Rate Request of Y > X, then the sender knows that either some router along the path malfunctioned (increasing the Rate Request inappropriately), or the receiver is lying about the Rate Request in the received packet.
送付者で。 例えば、送付者がXのRate Requestとクィック-スタートRequest、およびY>XのRate Requestと共にクィック-スタートRequestを受けた受信機レポートを送るなら、送付者は、経路に沿った何らかのルータが誤動作したか(Rate Requestを不適当に増加させて)、またはRate Requestに関して受信機が容認されたパケットにあるのを知っています。
If the sender sends a Quick-Start Request with a Rate Request of Z, the receiver receives the Quick-Start Request with an approved Rate Request of X, and reports a Rate Request of Y, for X < Y <= Z, then the receiver only succeeds in lying to the sender about the approved rate if the receiver successfully reports the rightmost 2Y bits in the QS nonce.
送付者がZのRate Requestとクィック-スタートRequestを送るなら、受信機は、Xの承認されたRate Requestと共にクィック-スタートRequestを受けて、YのRate Requestを報告して、X<Y<=Zに関して、次に、受信機は、受信機がQS一回だけで首尾よく一番右の2Yビットを報告するなら承認されたレートに関して送付者に嘘をつくのに成功するだけです。
If senders often use a configured default value for the Rate Request, then receivers would often be able to guess the original Rate Request, and this would make it easier for the receiver to lie about the value of the Rate Request field. Similarly, if the receiver often communicates with a particular sender, and the sender always uses the same Rate Request for that receiver, then the receiver might over time be able to infer the original Rate Request used by the sender.
送付者がRate Requestにしばしば構成されたデフォルト値を使用するなら、受信機はしばしばオリジナルのRate Requestを推測できるでしょう、そして、これで、Rate Request分野の値に関して受信機があるのが、より簡単になるでしょう。 同様に、受信機がしばしば特定の送付者とコミュニケートして、送付者がその受信機にいつも同じRate Requestを使用するなら、受信機は時間がたつにつれて、送付者によって使用されたオリジナルのRate Requestを推論できるかもしれません。
There are several possible additional forms of protection against receivers lying about the value of the Rate Request. One possible additional protection would be for a router that decreases a Rate Request in a Quick-Start Request to report the decrease directly to the sender. However, this could lead to many reports back to the sender for a single request, and could also be used in address- spoofing attacks.
Rate Requestの値に関してある受信機に対する保護のいくつかの可能な追加フォームがあります。 1つの可能な追加保護が直接送付者に減少を報告するためにクィック-スタートRequestでRate Requestを減少させるルータのためのものでしょう。 しかしながら、これは、ただ一つの要求のために送付者への多くのレポートに通じることができて、また、攻撃をだましながら、アドレスで使用できました。
A second limited form of protection would be for senders to use some degree of randomization in the requested Rate Request, so that it is difficult for receivers to guess the original value for the Rate Request. However, this is difficult because there is a fairly coarse granularity in the set of rate requests available to the sender, and randomizing the initial request only offers limited protection, in any case.
2番目の限局型の保護は送付者が要求されたRate Requestのいくらかの無作為化を使用するだろうことです、受信機に、Rate Requestのために元の値を推測するのが難しいように。 しかしながら、送付者にとって、利用可能なレート要求のセットにかなり粗い粒状があるので、これは難しいです、そして、初期の要求をランダマイズすると、限定保護は提供されるだけです、どのような場合でも。
9.4.4. Collusion between Misbehaving Routers
9.4.4. ふらちな事するルータの間の共謀
In addition to protecting against misbehaving receivers, it is necessary to protect against misbehaving routers. Consider collusion between an ingress router and an egress router belonging to the same intranet. The ingress router could decrement the Rate Request at the ingress, with the egress router increasing it again at the egress. The routers between the ingress and egress that approved the
ふらちな事する受信機から守ることに加えて、ふらちな事するルータから守るのが必要です。 同じイントラネットに属して、イングレスルータと出口ルータの間で共謀を考えてください。 イングレスルータはイングレスでRate Requestを減少させるかもしれません、出口ルータが再び出口でそれを増加させていて。 それが承認したイングレスと出口の間のルータ
Floyd, et al. Experimental [Page 44] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[44ページ]RFC4782クィックスタートとIP2007年1月
decremented rate request might not have been willing to approve the larger, original request.
減少したレート要求は、より大きくて、オリジナルの要求を承認することを望んでいなかったかもしれません。
Another form of collusion would be for the ingress router to inform the egress router out-of-band of the TTL Diff and QS Nonce for the request packet at the ingress. This would enable the egress router to modify the QS TTL and QS Nonce so that it appeared that all the routers along the path had approved the request. There does not appear to be any protection against a colluding ingress and egress router. Even if an intermediate router had deleted the Quick-Start Option from the packet, the ingress router could have sent the Quick-Start Option to the egress router out-of-band, with the egress router inserting the Quick-Start Option, with a modified QS TTL field, back in the packet.
別の形式の共謀はイングレスルータがリクエスト・パケットのためにバンドの外でTTL DiffとQS Nonceについてイングレスで出口ルータを知らせるだろうことです。 これは、出口ルータがQS TTLとQS Nonceを変更するのを可能にするでしょう、したがって、経路に沿ったすべてのルータが要求を承認したように見えました。 馴れ合うイングレスと出口ルータに対する少しの保護もあるように見えません。 中間的ルータがパケットからクィック-スタートOptionを削除したとしても、イングレスルータはバンドの外でクィック-スタートOptionを出口ルータに送ったかもしれないでしょうに、出口ルータがクィック-スタートOptionを挿入していて、変更されたQS TTL分野で、パケットで。
However, unlike ECN, there is somewhat less of an incentive for cooperating ingress and egress routers to collude to falsely modify the Quick-Start Request so that it appears to have been approved by all the routers along the path. With ECN, a colluding ingress router could falsely mark a packet as ECN-capable, with the colluding egress router returning the ECN field in the IP header to its original non- ECN-capable codepoint, and congested routers along the path could have been fooled into not dropping that packet. This collusion would give an unfair competitive advantage to the traffic protected by the colluding ingress and egress routers.
しかしながら、いくらか協力関係を持っているイングレスと出口ルータが間違ってクィック-スタートRequestを変更するために馴れ合う誘因の以下が電子証券取引ネットワークと異なっているので、それは経路に沿ったすべてのルータによって承認されたように見えます。 電子証券取引ネットワークと共に、経路に沿った電子証券取引ネットワークできて馴れ合っている出口ルータがオリジナルの電子証券取引ネットワークできる非codepointにIPヘッダーの電子証券取引ネットワーク野原を返していて、混雑しているルータがそのパケットを落とさないようにだまされたかもしれないように馴れ合っているイングレスルータはパケットを間違ってマークするかもしれません。 この共謀は馴れ合うイングレスと出口ルータによって保護された交通に不公平な競争力において有利な立場を与えるでしょう。
In contrast, with Quick-Start, the collusion of the ingress and egress routers to make it falsely appear that a Quick-Start Request was approved sometimes would give an advantage to the traffic covered by that collusion, and sometimes would give a disadvantage, depending on the details of the scenario. If some router along the path really does not have enough available bandwidth to approve the Quick-Start Request, then Quick-Start packets sent as a result of the falsely approved request could be dropped in the network, to the possible disadvantage of the connection. Thus, while the ingress and egress routers could collude to prevent intermediate routers from denying a Quick-Start Request, it would not always be to the connection's advantage for this to happen. One defense against such a collusion would be for some router between the ingress and egress nodes that denied the request to monitor connection performance, penalizing connections that seem to be using Quick-Start after a Quick-Start Request was denied, or that are reporting an Approved Rate higher than that actually approved by that router.
対照的に、クィック-スタートRequestが承認されたのを間違って現れさせるイングレスと出口ルータの共謀は、クィック-始めと共に、時々その共謀でカバーされた交通の利点を与えて、不都合を時々与えるでしょう、シナリオの詳細によって。 経路に沿った何らかのルータにクィック-スタートRequestを承認できるくらいの利用可能な帯域幅が本当にないなら、間違って承認された要求の結果、送られたクィック-スタートパケットはネットワークで落とされるかもしれません、接続の可能な不都合に。 したがって、イングレスと出口ルータは中間的ルータがクィック-スタートRequestを否定するのを防ぐために馴れ合うことができましたが、これが起こる接続の利点にはそれがいつもあるというわけではないでしょう。 接続性能をモニターするという要求を否定したイングレスと出口ノードの間には、そのような共謀に対する1つのディフェンスが何らかのルータのためにあるでしょう、クィック-スタートRequestが否定された後にクィック-始めを使用しているように思えるか、またはApproved Rateがそれが実際にそのルータで承認したより高いと報告している接続を罰して。
If the congested router is ECN-capable, and the colluding ingress and egress routers are lying about ECN-capability as well as about Quick-Start, then the result could be that the Quick-Start Request falsely appears to the sender to have been approved, and the Quick-
混雑しているルータが電子証券取引ネットワークできて、電子証券取引ネットワーク-能力の周りと、そして、クィック-始めの周りに関して馴れ合うイングレスと出口ルータがあるなら、結果は、承認されていてクィックであったためにはクィック-スタートRequestが送付者にとって間違って現れるということであるかもしれません。
Floyd, et al. Experimental [Page 45] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[45ページ]RFC4782クィックスタートとIP2007年1月
Start packets falsely appear to the congested router to be ECN- capable. In this case, the colluding routers might succeed in giving a competitive advantage to the traffic protected by their collusion (if no intermediate router is monitoring to catch such misbehavior).
スタートパケットは間違ってできる電子証券取引ネットワークである混雑しているルータに現れます。 この場合、馴れ合うルータは、彼らの共謀で保護された交通に競争力において有利な立場を与えるのに成功するかもしれません(どんな中間的ルータもそのような不正行為をキャッチにモニターしていないなら)。
9.5. Misbehaving Middleboxes and the IP TTL
9.5. ふらちな事をしているMiddleboxesとIP TTL
One possible difficulty is that of traffic normalizers [HKP01], or other middleboxes along that path, that rewrite IP TTLs in order to foil other kinds of attacks in the network. If such a traffic normalizer rewrote the IP TTL, but did not adjust the Quick-Start TTL by the same amount, then the sender's mechanism for determining if the request was approved by all routers along the path would no longer be reliable. Rewriting the IP TTL could result in false positives (with the sender incorrectly believing that the Quick- Start Request was approved) as well as false negatives (with the sender incorrectly believing that the Quick-Start Request was denied).
ネットワークで他の種類の攻撃をくじくためにIP TTLsを書き直す交通正規化群[HKP01]、またはその経路に沿った他のmiddleboxesで困難がそれであることが可能な1つ。 そのような交通正規化群がIP TTLを書き直しましたが、同じ量に応じてクィック-スタートTTLを調整しないなら、要求が経路に沿ったすべてのルータによって承認されたかどうか決定するための送付者のメカニズムはもう信頼できないでしょうに。 IP TTLを書き直すと、無病誤診は有病誤診(送付者が、クィック-スタートRequestが否定されたと不当に信じている)と同様にもたらされるかもしれません(送付者が、クィックスタートRequestが承認されたと不当に信じていて)。
9.6. Attacks on Quick-Start
9.6. クィックスタートに対する攻撃
As discussed in [SAF06], Quick-Start is vulnerable to two kinds of attacks: (1) attacks to increase the routers' processing and state load and (2) attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections. Routers can protect against the first kind of attack by applying a simple limit on the rate at which Quick-Start Requests will be considered by the router.
[SAF06]で議論するように、クィック-始めは2種類の攻撃に傷つきやすいです: (1) ルータの処理と状態を増加させる攻撃はロードされます、そして、(2)は一時利用可能なクィック-スタート帯域幅をタイアップするためににせのクィック-スタートRequestsと共に攻撃されます、承認しているクィック-スタートRequestsから他の接続からルータを防いで。 ルータは、クィック-スタートRequestsがルータによって考えられるレートにおける簡単な限界を適用することによって、最初の種類の攻撃から守ることができます。
The second kind of attack, to tie up the available Quick-Start bandwidth, is more difficult to defend against. As discussed in [SAF06], Quick-Start Requests that are not going to be used, either because they are from malicious attackers or because they are denied by routers downstream, can result in short-term `wasting' of potential Quick-Start bandwidth, resulting in routers denying subsequent Quick-Start Requests that, if approved, would in fact have been used.
2番目の種類の攻撃は防御するのが利用可能なクィック-スタート帯域幅への繋がりにより難しいです。 [SAF06]で議論するように、彼らが悪意がある攻撃者から来ているか、または彼らがルータ川下で否定されるので使用されなかったクィック-スタートRequestsは潜在的クィック-スタート帯域幅について短期的な'むだになること'をもたらすことができます、承認されるなら事実上、使用されたその後のクィック-スタートRequestsを否定するルータをもたらして。
We note that the likelihood of malicious attacks would be minimized significantly when Quick-Start was deployed in a controlled environment such as an intranet, where there was some form of centralized control over the users in the system. We also note that this form of attack could potentially make Quick-Start unusable, but it would not do any further damage; in the worst case, the network would function as a network without Quick-Start.
クィック-始めがユーザの上にシステムには何らかの形式の集中制御があったイントラネットなどの制御環境で配備されたとき、私たちは、悪意ある攻撃の見込みがかなり最小にされることに注意します。 また、私たちは、この形式の攻撃でクィック-始めが潜在的に使用不可能になるかもしれないことに注意しますが、少しのさらなる損害も与えないでしょう。 最悪の場合には、ネットワークはネットワークとしてクィック-始めなしで機能するでしょう。
Floyd, et al. Experimental [Page 46] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[46ページ]RFC4782クィックスタートとIP2007年1月
[SAF06] considers the potential of Extreme Quick-Start algorithms at routers, which keep per-flow state for Quick-Start connections, in protecting the availability of Quick-Start bandwidth in the face of frequent, overly large Quick-Start Requests.
[SAF06]はルータでExtremeクィック-スタートアルゴリズムの可能性を考えます、頻繁で、ひどく大きいクィック-スタートRequestsに直面してクィック-スタート帯域幅の有用性を保護する際に。(ルータはクィック-スタート接続のために1流れあたりの状態を維持します)。
9.7. Simulations with Quick-Start
9.7. クィックスタートとのシミュレーション
Quick-Start was added to the NS simulator [SH02] by Srikanth Sundarrajan, and additional functionality was added by Pasi Sarolahti. The validation test is at `test-all-quickstart' in the `tcl/test' directory in NS. The initial simulation studies from [SH02] show a significant performance improvement using Quick-Start for moderate-sized flows (between 4 KB and 128 KB) in underutilized environments. These studies are of file transfers, with the improvement measured as the relative increase in the overall throughput for the file transfer. The study shows that potential improvement from Quick-Start is proportional to the delay-bandwidth product of the path.
迅速な始めはSrikanth SundarrajanによってNSシミュレータ[SH02]に加えられました、そして、追加機能性はパシSarolahtiによって加えられました。 合法化テストがNSの'tcl/テスト'ディレクトリの'試しにオールquickstart'にあります。 [SH02]からの初期のシミュレーション研究は、中道主義者サイズの流れ(4KBと128KBの間の)にunderutilized環境でクィック-始めを使用することで顕著な性能改良を示しています。 これらの研究はファイル転送のものです、改良がファイル転送のための総合的なスループットの相対的増加として測定されている状態で。 研究は、クィック-始めからの潜在的改良が経路の遅れ帯域幅生成物に比例しているのを示します。
The Quick-Start simulations in [SAF06] explore the following: the potential benefit of Quick-Start for the connection, the relative benefits of different router-based algorithms for approving Quick- Start Requests, and the effectiveness of Quick-Start as a function of the senders' algorithms for choosing the size of the rate request.
The Quick-Start simulations in [SAF06] explore the following: the potential benefit of Quick-Start for the connection, the relative benefits of different router-based algorithms for approving Quick- Start Requests, and the effectiveness of Quick-Start as a function of the senders' algorithms for choosing the size of the rate request.
10. Implementation and Deployment Issues
10. Implementation and Deployment Issues
This section discusses some of the implementation issues with Quick- Start. This section also discusses some of the key deployment issues, such as the chicken-and-egg deployment problems of mechanisms that have to be deployed in both routers and end nodes in order to work, and the problems posed by the wide deployment of middleboxes today that block the use of known or unknown IP Options.
This section discusses some of the implementation issues with Quick- Start. This section also discusses some of the key deployment issues, such as the chicken-and-egg deployment problems of mechanisms that have to be deployed in both routers and end nodes in order to work, and the problems posed by the wide deployment of middleboxes today that block the use of known or unknown IP Options.
10.1. Implementation Issues for Sending Quick-Start Requests
10.1. Implementation Issues for Sending Quick-Start Requests
Section 4.7 discusses some of the issues with deciding the initial sending rate to request. Quick-Start raises additional issues about the communication between the transport protocol and the application, and about the use of past history with Quick-Start in the end node.
Section 4.7 discusses some of the issues with deciding the initial sending rate to request. Quick-Start raises additional issues about the communication between the transport protocol and the application, and about the use of past history with Quick-Start in the end node.
One possibility is that a protocol implementation could provide an API for applications to indicate when they want to request Quick- Start, and what rate they would like to request. In the conventional socket API, this could be a socket option that is set before a connection is established. Some applications, such as those that use TCP for bulk transfers, do not have interest in the transmission rate, but they might know the amount of data that can be sent
One possibility is that a protocol implementation could provide an API for applications to indicate when they want to request Quick- Start, and what rate they would like to request. In the conventional socket API, this could be a socket option that is set before a connection is established. Some applications, such as those that use TCP for bulk transfers, do not have interest in the transmission rate, but they might know the amount of data that can be sent
Floyd, et al. Experimental [Page 47] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 47] RFC 4782 Quick-Start for TCP and IP January 2007
immediately. Based on this, the sender implementation could decide whether Quick-Start would be useful, and what rate should be requested.
immediately. Based on this, the sender implementation could decide whether Quick-Start would be useful, and what rate should be requested.
We note that when Quick-Start is used, the TCP sender is required to save the QS Nonce and the TTL Diff when the Quick-Start Request is sent, and to implement an additional timer for the paced transmission of Quick-Start packets.
We note that when Quick-Start is used, the TCP sender is required to save the QS Nonce and the TTL Diff when the Quick-Start Request is sent, and to implement an additional timer for the paced transmission of Quick-Start packets.
10.2. Implementation Issues for Processing Quick-Start Requests
10.2. Implementation Issues for Processing Quick-Start Requests
A router or other network host must be able to determine the approximate bandwidth of its outbound network interfaces in order to process incoming Quick-Start rate requests, including those that originate from the host itself. One possibility would be for hosts to rely on configuration information to determine link bandwidths; this has the drawback of not being robust to errors in configuration. Another possibility would be for network device drivers to infer the bandwidth for the interface and to communicate this to the IP layer.
A router or other network host must be able to determine the approximate bandwidth of its outbound network interfaces in order to process incoming Quick-Start rate requests, including those that originate from the host itself. One possibility would be for hosts to rely on configuration information to determine link bandwidths; this has the drawback of not being robust to errors in configuration. Another possibility would be for network device drivers to infer the bandwidth for the interface and to communicate this to the IP layer.
Particular issues will arise for wireless links with variable bandwidth, where decisions will have to be made about how frequently the host gets updates of the changing bandwidth. It seems appropriate that Quick-Start Requests would be handled particularly conservatively for links with variable bandwidth; to avoid cases where Quick-Start Requests are approved, the link bandwidth is reduced, and the data packets that are sent end up being dropped.
Particular issues will arise for wireless links with variable bandwidth, where decisions will have to be made about how frequently the host gets updates of the changing bandwidth. It seems appropriate that Quick-Start Requests would be handled particularly conservatively for links with variable bandwidth; to avoid cases where Quick-Start Requests are approved, the link bandwidth is reduced, and the data packets that are sent end up being dropped.
Difficult issues also arise for paths with multi-access links (e.g., Ethernet). Routers or end-nodes with multi-access links should be particularly conservative in granting Quick-Start Requests. In particular, for some multi-access links, there may be no procedure for an attached node to use to determine whether all parts of the multi-access link have been underutilized in the recent past.
Difficult issues also arise for paths with multi-access links (e.g., Ethernet). Routers or end-nodes with multi-access links should be particularly conservative in granting Quick-Start Requests. In particular, for some multi-access links, there may be no procedure for an attached node to use to determine whether all parts of the multi-access link have been underutilized in the recent past.
10.3. Possible Deployment Scenarios
10.3. Possible Deployment Scenarios
Because of possible problems discussed above concerning using Quick- Start over some network paths and the security issues discussed in Section 11, the most realistic initial deployment of Quick-Start would most likely take place in intranets and other controlled environments. Quick-Start is most useful on high bandwidth-delay paths that are significantly underutilized. The primary initial users of Quick-Start would likely be in organizations that provide network services to their users and also have control over a large portion of the network path.
Because of possible problems discussed above concerning using Quick- Start over some network paths and the security issues discussed in Section 11, the most realistic initial deployment of Quick-Start would most likely take place in intranets and other controlled environments. Quick-Start is most useful on high bandwidth-delay paths that are significantly underutilized. The primary initial users of Quick-Start would likely be in organizations that provide network services to their users and also have control over a large portion of the network path.
Floyd, et al. Experimental [Page 48] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 48] RFC 4782 Quick-Start for TCP and IP January 2007
Quick-Start is not currently intended for ubiquitous deployment in the global Internet. In particular, Quick-Start should not be enabled by default in end-nodes or in routers; instead, when Quick- Start is used, it should be explicitly enabled by users or system administrators.
Quick-Start is not currently intended for ubiquitous deployment in the global Internet. In particular, Quick-Start should not be enabled by default in end-nodes or in routers; instead, when Quick- Start is used, it should be explicitly enabled by users or system administrators.
Below are a few examples of networking environments where Quick- Start would potentially be useful. These are the environments that might consider an initial deployment of Quick-Start in the routers and end-nodes, where the incentives for routers to deploy Quick- Start might be the most clear.
Below are a few examples of networking environments where Quick- Start would potentially be useful. These are the environments that might consider an initial deployment of Quick-Start in the routers and end-nodes, where the incentives for routers to deploy Quick- Start might be the most clear.
* Centrally administrated organizational intranets: These intranets
often have large network capacity, with networks that are
underutilized for much of the time [PABL+05]. Such intranets might
also include high-bandwidth and high-delay paths to remote sites.
In such an environment, Quick-Start would be of benefit to users,
and there would be a clear incentive for the deployment of Quick-
Start in routers. For example, Quick-Start could be quite useful
in high-bandwidth networks used for scientific computing.
* Centrally administrated organizational intranets: These intranets often have large network capacity, with networks that are underutilized for much of the time [PABL+05]. Such intranets might also include high-bandwidth and high-delay paths to remote sites. In such an environment, Quick-Start would be of benefit to users, and there would be a clear incentive for the deployment of Quick- Start in routers. For example, Quick-Start could be quite useful in high-bandwidth networks used for scientific computing.
* Wireless networks: Quick-Start could also be useful in high-delay
environments of Cellular Wide-Area Wireless Networks, such as the
GPRS [BW97] and their enhancements and next generations. For
example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to
provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte
packets per second) while the GPRS round-trip times range typically
from a few hundred milliseconds to over a second, excluding any
possible queueing delays in the network [GPAR02]. In addition,
these networks sometimes have variable additional delays due to
resource allocation that could be avoided by keeping the connection
path constantly utilized, starting from initial slow-start. Thus,
Quick-Start could be of significant benefit to users in these
environments.
* Wireless networks: Quick-Start could also be useful in high-delay environments of Cellular Wide-Area Wireless Networks, such as the GPRS [BW97] and their enhancements and next generations. For example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per second) while the GPRS round-trip times range typically from a few hundred milliseconds to over a second, excluding any possible queueing delays in the network [GPAR02]. In addition, these networks sometimes have variable additional delays due to resource allocation that could be avoided by keeping the connection path constantly utilized, starting from initial slow-start. Thus, Quick-Start could be of significant benefit to users in these environments.
* Paths over satellite links: Geostationary Orbit (GEO) satellite
links have one-way propagation delays on the order of 250 ms while
the bandwidth can be measured in megabits per second [RFC2488].
Because of the considerable bandwidth-delay product on the link,
TCP's slow-start is a major performance limitation in the beginning
of the connection. A large initial congestion window would be
useful to users of such satellite links.
* Paths over satellite links: Geostationary Orbit (GEO) satellite links have one-way propagation delays on the order of 250 ms while the bandwidth can be measured in megabits per second [RFC2488]. Because of the considerable bandwidth-delay product on the link, TCP's slow-start is a major performance limitation in the beginning of the connection. A large initial congestion window would be useful to users of such satellite links.
* Single-hop paths: Quick-Start should work well over point-to-point
single-hop paths, e.g., from a host to an adjacent server. Quick-
Start would work over a single-hop IP path consisting of a multi-
access link only if the host was able to determine if the path to
the next IP hop has been significantly underutilized over the
* Single-hop paths: Quick-Start should work well over point-to-point single-hop paths, e.g., from a host to an adjacent server. Quick- Start would work over a single-hop IP path consisting of a multi- access link only if the host was able to determine if the path to the next IP hop has been significantly underutilized over the
Floyd, et al. Experimental [Page 49] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 49] RFC 4782 Quick-Start for TCP and IP January 2007
recent past. If the multi-access link includes a layer-2 switch,
then the attached host cannot necessarily determine the status of
the other links in the layer-2 network.
recent past. If the multi-access link includes a layer-2 switch, then the attached host cannot necessarily determine the status of the other links in the layer-2 network.
10.4. A Comparison with the Deployment Problems of ECN
10.4. A Comparison with the Deployment Problems of ECN
Given the glacially slow rate of deployment of ECN in the Internet to date [MAF05], it is disconcerting to note that some of the deployment problems of Quick-Start are even greater than those of ECN. First, unlike ECN, which can be of benefit even if it is only deployed on one of the routers along the end-to-end path, a connection's use of Quick-Start requires Quick-Start deployment on all of the routers along the end-to-end path. Second, unlike ECN, which uses an allocated field in the IP header, Quick-Start requires the extra complications of an IP Option, which can be difficult to pass through the current Internet [MAF05].
Given the glacially slow rate of deployment of ECN in the Internet to date [MAF05], it is disconcerting to note that some of the deployment problems of Quick-Start are even greater than those of ECN. First, unlike ECN, which can be of benefit even if it is only deployed on one of the routers along the end-to-end path, a connection's use of Quick-Start requires Quick-Start deployment on all of the routers along the end-to-end path. Second, unlike ECN, which uses an allocated field in the IP header, Quick-Start requires the extra complications of an IP Option, which can be difficult to pass through the current Internet [MAF05].
However, in spite of these issues, there is some hope for the deployment of Quick-Start, at least in protected corners of the Internet, because the potential benefits of Quick-Start to the user are considerably more dramatic than those of ECN. Rather than simply replacing the occasional dropped packet by an ECN-marked packet, Quick-Start is capable of dramatically increasing the throughput of connections in underutilized environments [SAF06].
However, in spite of these issues, there is some hope for the deployment of Quick-Start, at least in protected corners of the Internet, because the potential benefits of Quick-Start to the user are considerably more dramatic than those of ECN. Rather than simply replacing the occasional dropped packet by an ECN-marked packet, Quick-Start is capable of dramatically increasing the throughput of connections in underutilized environments [SAF06].
11. Security Considerations
11. Security Considerations
Sections 9.4 and 9.6 discuss the security considerations related to Quick-Start. Section 9.4 discusses the potential abuse of Quick- Start by senders or receivers lying about whether the request was approved or about the approved rate, and of routers in collusion to misuse Quick-Start. Section 9.5 discusses potential problems with traffic normalizers that rewrite IP TTLs in packet headers. All these problems could result in the sender using a Rate Request that was inappropriately large, or thinking that a request was approved when it was in fact denied by at least one router along the path. This inappropriate use of Quick-Start could result in congestion and an unacceptable level of packet drops along the path. Such congestion could also be part of a Denial of Service attack.
Sections 9.4 and 9.6 discuss the security considerations related to Quick-Start. Section 9.4 discusses the potential abuse of Quick- Start by senders or receivers lying about whether the request was approved or about the approved rate, and of routers in collusion to misuse Quick-Start. Section 9.5 discusses potential problems with traffic normalizers that rewrite IP TTLs in packet headers. All these problems could result in the sender using a Rate Request that was inappropriately large, or thinking that a request was approved when it was in fact denied by at least one router along the path. This inappropriate use of Quick-Start could result in congestion and an unacceptable level of packet drops along the path. Such congestion could also be part of a Denial of Service attack.
Section 9.6 discusses a potential attack on the routers' processing and state load from an attack of Quick-Start Requests. Section 9.6 also discusses a potential attack on the available Quick-Start bandwidth by sending bogus Quick-Start Requests for bandwidth that will not, in fact, be used. While this impacts the global usability of Quick-Start, it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available.
Section 9.6 discusses a potential attack on the routers' processing and state load from an attack of Quick-Start Requests. Section 9.6 also discusses a potential attack on the available Quick-Start bandwidth by sending bogus Quick-Start Requests for bandwidth that will not, in fact, be used. While this impacts the global usability of Quick-Start, it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available.
Floyd, et al. Experimental [Page 50] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 50] RFC 4782 Quick-Start for TCP and IP January 2007
Section 4.7.2 discusses the potential problem of packets with Quick- Start Requests dropped by middleboxes along the path.
Section 4.7.2 discusses the potential problem of packets with Quick- Start Requests dropped by middleboxes along the path.
As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start Option is a mutable IPv4 option and hence completely zeroed for AH ICV calculation purposes. This is also the treatment required by RFC 4302 for unrecognized IPv4 options. The IPv6 Quick-Start Option's IANA-allocated option type indicates that it is a mutable option; hence, according to RFC 4302, its option data is required to be zeroed for AH ICV computation purposes. See RFC 4302 for further explanation.
As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start Option is a mutable IPv4 option and hence completely zeroed for AH ICV calculation purposes. This is also the treatment required by RFC 4302 for unrecognized IPv4 options. The IPv6 Quick-Start Option's IANA-allocated option type indicates that it is a mutable option; hence, according to RFC 4302, its option data is required to be zeroed for AH ICV computation purposes. See RFC 4302 for further explanation.
Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case, it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive.
Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case, it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive.
We note two high-order points here. First, the Quick-Start Nonce goes a long way towards preventing large-scale cheating. Second, even if a host occasionally uses Quick-Start when it is not approved by the entire network path, the network will not collapse. Quick- Start does not remove TCP's basic congestion control mechanisms; these will kick in when the network is heavily loaded, relegating any Quick-Start mistake to a transient.
We note two high-order points here. First, the Quick-Start Nonce goes a long way towards preventing large-scale cheating. Second, even if a host occasionally uses Quick-Start when it is not approved by the entire network path, the network will not collapse. Quick- Start does not remove TCP's basic congestion control mechanisms; these will kick in when the network is heavily loaded, relegating any Quick-Start mistake to a transient.
Floyd, et al. Experimental [Page 51] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 51] RFC 4782 Quick-Start for TCP and IP January 2007
12. IANA Considerations
12. IANA Considerations
Quick-Start requires an IP Option and a TCP Option.
Quick-Start requires an IP Option and a TCP Option.
12.1. IP Option
12.1. IP Option
Quick-Start requires both an IPv4 Option Number (Section 3.1) and an IPv6 Option Number (Section 3.2).
Quick-Start requires both an IPv4 Option Number (Section 3.1) and an IPv6 Option Number (Section 3.2).
IPv4 Option Number:
IPv4 Option Number:
Copy Class Number Value Name
---- ----- ------ ----- ----
0 00 25 25 QS - Quick-Start
Copy Class Number Value Name ---- ----- ------ ----- ---- 0 00 25 25 QS - Quick-Start
IPv6 Option Number [RFC2460]:
IPv6 Option Number [RFC2460]:
HEX act chg rest
--- --- --- -----
6 00 1 00110 Quick-Start
HEX act chg rest --- --- --- ----- 6 00 1 00110 Quick-Start
For the IPv6 Option Number, the first two bits indicate that the IPv6 node may skip over this option and continue processing the header if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en-route.
For the IPv6 Option Number, the first two bits indicate that the IPv6 node may skip over this option and continue processing the header if it doesn't recognize the option type, and the third bit indicates that the Option Data may change en-route.
In both cases, this document should be listed as the reference document.
In both cases, this document should be listed as the reference document.
12.2. TCP Option
12.2. TCP Option
Quick-Start requires a TCP Option Number (Section 4.2).
Quick-Start requires a TCP Option Number (Section 4.2).
TCP Option Number:
TCP Option Number:
Kind Length Meaning
---- ------ ------------------------------
27 8 Quick-Start Response
Kind Length Meaning ---- ------ ------------------------------ 27 8 Quick-Start Response
This document should be listed as the reference document.
This document should be listed as the reference document.
Floyd, et al. Experimental [Page 52] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 52] RFC 4782 Quick-Start for TCP and IP January 2007
13. Conclusions
13. Conclusions
We are presenting the Quick-Start mechanism as a simple, understandable, and incrementally deployable mechanism that would be sufficient to allow some connections to start up with large initial rates, or large initial congestion windows, in over-provisioned, high-bandwidth environments. We expect there will be an increasing number of over-provisioned, high-bandwidth environments where the Quick-Start mechanism, or another mechanism of similar power, could be of significant benefit to a wide range of traffic. We are presenting the Quick-Start mechanism as a request for the community to provide feedback and experimentation on issues relating to Quick- Start.
We are presenting the Quick-Start mechanism as a simple, understandable, and incrementally deployable mechanism that would be sufficient to allow some connections to start up with large initial rates, or large initial congestion windows, in over-provisioned, high-bandwidth environments. We expect there will be an increasing number of over-provisioned, high-bandwidth environments where the Quick-Start mechanism, or another mechanism of similar power, could be of significant benefit to a wide range of traffic. We are presenting the Quick-Start mechanism as a request for the community to provide feedback and experimentation on issues relating to Quick- Start.
14. Acknowledgements
14. Acknowledgements
The authors wish to thank Mark Handley for discussions of these issues. The authors also thank the End-to-End Research Group, the Transport Services Working Group, and members of IPAM's program on Large-Scale Communication Networks for both positive and negative feedback on this proposal. We thank Srikanth Sundarrajan for the initial implementation of Quick-Start in the NS simulator, and for the initial simulation study. Many thanks to David Black and Joe Touch for extensive feedback on Quick-Start and IP tunnels. We also thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi, and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for the suggestion of adding the QS Nonce to the Report of Approved Rate.
The authors wish to thank Mark Handley for discussions of these issues. The authors also thank the End-to-End Research Group, the Transport Services Working Group, and members of IPAM's program on Large-Scale Communication Networks for both positive and negative feedback on this proposal. We thank Srikanth Sundarrajan for the initial implementation of Quick-Start in the NS simulator, and for the initial simulation study. Many thanks to David Black and Joe Touch for extensive feedback on Quick-Start and IP tunnels. We also thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi, and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for the suggestion of adding the QS Nonce to the Report of Approved Rate.
The version of the QS Nonce in this document is based on a proposal from Guohan Lu [L05]. Earlier versions of this document contained an eight-bit QS Nonce, and subsequent versions discussed the possibility of a four-bit QS Nonce.
The version of the QS Nonce in this document is based on a proposal from Guohan Lu [L05]. Earlier versions of this document contained an eight-bit QS Nonce, and subsequent versions discussed the possibility of a four-bit QS Nonce.
This document builds upon the concepts described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start in tunnels was borrowed directly from RFC 3168.
This document builds upon the concepts described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start in tunnels was borrowed directly from RFC 3168.
This document is the development of a proposal originally by Amit Jain for Initial Window Discovery.
This document is the development of a proposal originally by Amit Jain for Initial Window Discovery.
Floyd, et al. Experimental [Page 53] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 53] RFC 4782 Quick-Start for TCP and IP January 2007
Appendix A. Related Work
Appendix A. Related Work
The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649] or other transport protocols for high-bandwidth transfers, could go a significant way towards extending the range of performance for best- effort traffic in the Internet. However, there are many things that the Quick-Start proposal would not accomplish. Quick-Start is not a congestion control mechanism, and would not help in making more precise use of the available bandwidth -- that is, of achieving the goal of high throughput with low delay and low packet-loss rates. Quick-Start would not give routers more control over the decrease rates of active connections.
The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649] or other transport protocols for high-bandwidth transfers, could go a significant way towards extending the range of performance for best- effort traffic in the Internet. However, there are many things that the Quick-Start proposal would not accomplish. Quick-Start is not a congestion control mechanism, and would not help in making more precise use of the available bandwidth -- that is, of achieving the goal of high throughput with low delay and low packet-loss rates. Quick-Start would not give routers more control over the decrease rates of active connections.
In addition, any evaluation of Quick-Start must include a discussion of the relative benefits of approaches that use no explicit information from routers, and of approaches that use more fine- grained feedback from routers as part of a larger congestion control mechanism. We discuss several classes of proposals in the sections below.
In addition, any evaluation of Quick-Start must include a discussion of the relative benefits of approaches that use no explicit information from routers, and of approaches that use more fine- grained feedback from routers as part of a larger congestion control mechanism. We discuss several classes of proposals in the sections below.
A.1. Fast Start-Ups without Explicit Information from Routers
A.1. Fast Start-Ups without Explicit Information from Routers
One possibility would be for senders to use information from the packet streams to learn about the available bandwidth, without explicit information from routers. These techniques would not allow a start-up as fast as that available from Quick-Start in an underutilized environment; one already has to have sent some packets in order to use the packet stream to learn about available bandwidth. However, these techniques could allow a start-up considerably faster than the current Slow-Start. While it seems clear that approaches *without* explicit feedback from the routers will be strictly less powerful than is possible *with* explicit feedback, it is also possible that approaches that are more aggressive than Slow-Start are possible without the complexity involved in obtaining explicit feedback from routers.
One possibility would be for senders to use information from the packet streams to learn about the available bandwidth, without explicit information from routers. These techniques would not allow a start-up as fast as that available from Quick-Start in an underutilized environment; one already has to have sent some packets in order to use the packet stream to learn about available bandwidth. However, these techniques could allow a start-up considerably faster than the current Slow-Start. While it seems clear that approaches *without* explicit feedback from the routers will be strictly less powerful than is possible *with* explicit feedback, it is also possible that approaches that are more aggressive than Slow-Start are possible without the complexity involved in obtaining explicit feedback from routers.
Periodic packet streams: [JD02] explores the use of periodic packet streams to estimate the available bandwidth along a path. The idea is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the available bandwidth (due to an increasing queue). While [JD02] states that the proposed mechanism does not cause significant increases in network utilization, losses, or delays when done by one flow at a time, the approach could be problematic if conducted concurrently by a number of flows. [JD02] also gives an overview of some of the earlier work on inferring the available bandwidth from packet trains.
Periodic packet streams: [JD02] explores the use of periodic packet streams to estimate the available bandwidth along a path. The idea is that the one-way delays of a periodic packet stream show an increasing trend when the stream's rate is higher than the available bandwidth (due to an increasing queue). While [JD02] states that the proposed mechanism does not cause significant increases in network utilization, losses, or delays when done by one flow at a time, the approach could be problematic if conducted concurrently by a number of flows. [JD02] also gives an overview of some of the earlier work on inferring the available bandwidth from packet trains.
Floyd, et al. Experimental [Page 54] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 54] RFC 4782 Quick-Start for TCP and IP January 2007
Swift-Start: The Swift Start proposal from [PRAKS02] combines packet-pair and packet-pacing techniques. An initial congestion window of four segments is used to estimate the available bandwidth along the path. This estimate is then used to dramatically increase the congestion window during the second RTT of data transmission.
Swift-Start: The Swift Start proposal from [PRAKS02] combines packet-pair and packet-pacing techniques. An initial congestion window of four segments is used to estimate the available bandwidth along the path. This estimate is then used to dramatically increase the congestion window during the second RTT of data transmission.
SPAND: In the TCP/SPAND proposal from [ZQK00] for speeding up short data transfers, network performance information would be shared among many co-located hosts to estimate each connection's fair share of the network resources. Based on such estimation and the transfer size, the TCP sender would determine the optimal initial congestion window size. The design for TCP/SPAND uses a performance gateway that monitors all traffic entering and leaving an organization's network.
SPAND: In the TCP/SPAND proposal from [ZQK00] for speeding up short data transfers, network performance information would be shared among many co-located hosts to estimate each connection's fair share of the network resources. Based on such estimation and the transfer size, the TCP sender would determine the optimal initial congestion window size. The design for TCP/SPAND uses a performance gateway that monitors all traffic entering and leaving an organization's network.
Sharing information among TCP connections: The Congestion Manager [RFC3124] and TCP control block sharing [RFC2140] both propose sharing congestion information among multiple TCP connections with the same endpoints. With the Congestion Manager, a new TCP connection could start with a high initial cwnd, if it was sharing the path and the cwnd with a pre-existing TCP connection to the same destination that had already obtained a high congestion window. RFC 2140 discusses ensemble sharing, where an established connection's congestion window could be `divided up' to be shared with a new connection to the same host. However, neither of these approaches addresses the case of a connection to a new destination, with no existing or recent connection (and therefore congestion control state) to that destination.
Sharing information among TCP connections: The Congestion Manager [RFC3124] and TCP control block sharing [RFC2140] both propose sharing congestion information among multiple TCP connections with the same endpoints. With the Congestion Manager, a new TCP connection could start with a high initial cwnd, if it was sharing the path and the cwnd with a pre-existing TCP connection to the same destination that had already obtained a high congestion window. RFC 2140 discusses ensemble sharing, where an established connection's congestion window could be `divided up' to be shared with a new connection to the same host. However, neither of these approaches addresses the case of a connection to a new destination, with no existing or recent connection (and therefore congestion control state) to that destination.
While continued research on the limits of the ability of TCP and other transport protocols to learn of available bandwidth without explicit feedback from the router seems useful, we note that there are several fundamental advantages of explicit feedback from routers.
While continued research on the limits of the ability of TCP and other transport protocols to learn of available bandwidth without explicit feedback from the router seems useful, we note that there are several fundamental advantages of explicit feedback from routers.
(1) Explicit feedback is faster than implicit feedback:
One advantage of explicit feedback from the routers is that it
allows the transport sender to reliably learn of available
bandwidth in one round-trip time.
(1) Explicit feedback is faster than implicit feedback: One advantage of explicit feedback from the routers is that it allows the transport sender to reliably learn of available bandwidth in one round-trip time.
(2) Explicit feedback is more reliable than implicit feedback:
Techniques that attempt to assess the available bandwidth at
connection start-up using implicit techniques are more error-
prone than techniques that involve every element in the network
path. While explicit information from the network can be wrong,
it has a much better chance of being appropriate than an end-host
trying to *estimate* an appropriate sending rate using "block
box" probing techniques of the entire path.
(2) Explicit feedback is more reliable than implicit feedback: Techniques that attempt to assess the available bandwidth at connection start-up using implicit techniques are more error- prone than techniques that involve every element in the network path. While explicit information from the network can be wrong, it has a much better chance of being appropriate than an end-host trying to *estimate* an appropriate sending rate using "block box" probing techniques of the entire path.
Floyd, et al. Experimental [Page 55] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 55] RFC 4782 Quick-Start for TCP and IP January 2007
A.2. Optimistic Sending without Explicit Information from Routers
A.2. Optimistic Sending without Explicit Information from Routers
Another possibility that has been suggested [S02] is for the sender to start with a large initial window without explicit permission from the routers and without bandwidth estimation techniques and for the first packet of the initial window to contain information, such as the size or sending rate of the initial window. The proposal would be that congested routers would use this information in the first data packet to drop or delay many or all of the packets from that initial window. In this way, a flow's optimistically large initial window would not force the router to drop packets from competing flows in the network. Such an approach would seem to require some mechanism for the sender to ensure that the routers along the path understood the mechanism for marking the first packet of a large initial window.
Another possibility that has been suggested [S02] is for the sender to start with a large initial window without explicit permission from the routers and without bandwidth estimation techniques and for the first packet of the initial window to contain information, such as the size or sending rate of the initial window. The proposal would be that congested routers would use this information in the first data packet to drop or delay many or all of the packets from that initial window. In this way, a flow's optimistically large initial window would not force the router to drop packets from competing flows in the network. Such an approach would seem to require some mechanism for the sender to ensure that the routers along the path understood the mechanism for marking the first packet of a large initial window.
Obviously, there would be a number of questions to consider about an approach of optimistic sending.
Obviously, there would be a number of questions to consider about an approach of optimistic sending.
(1) Incremental deployment:
One question would be the potential complications of incremental
deployment, where some of the routers along the path might not
understand the packet information describing the initial window.
(1) Incremental deployment: One question would be the potential complications of incremental deployment, where some of the routers along the path might not understand the packet information describing the initial window.
(2) Congestion collapse:
There could also be concerns about congestion collapse if many
flows used large initial windows, many packets were dropped from
optimistic initial windows, and many congested links ended up
carrying packets that are only going to be dropped downstream.
(2) Congestion collapse: There could also be concerns about congestion collapse if many flows used large initial windows, many packets were dropped from optimistic initial windows, and many congested links ended up carrying packets that are only going to be dropped downstream.
(3) Distributed Denial of Service attacks:
A third question would be the potential role of optimistic
senders in amplifying the damage done by a Distributed Denial of
Service (DDoS) attack (assuming attackers use compliant
congestion control in the hopes of "flying under the radar").
(3) Distributed Denial of Service attacks: A third question would be the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service (DDoS) attack (assuming attackers use compliant congestion control in the hopes of "flying under the radar").
(4) Performance hits if a packet is dropped:
A fourth issue would be to quantify the performance hit to the
connection when a packet is dropped from one of the initial
windows.
(4) Performance hits if a packet is dropped: A fourth issue would be to quantify the performance hit to the connection when a packet is dropped from one of the initial windows.
A.3. Fast Start-Ups with Other Information from Routers
A.3. Fast Start-Ups with Other Information from Routers
There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path.
There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path.
Floyd, et al. Experimental [Page 56] RFC 4782 Quick-Start for TCP and IP January 2007
Floyd, et al. Experimental [Page 56] RFC 4782 Quick-Start for TCP and IP January 2007
An IP Option about the free buffer size: In related work, [P00] investigates the use of a slightly different IP option for TCP connections to discover the available bandwidth along the path. In that proposal, the IP option would query the routers along the path about the smallest available free buffer size. Also, the IP option would have been sent after the initial SYN exchange, when the TCP sender already had an estimate of the round- trip time.
An IP Option about the free buffer size: In related work, [P00] investigates the use of a slightly different IP option for TCP connections to discover the available bandwidth along the path. In that proposal, the IP option would query the routers along the path about the smallest available free buffer size. Also, the IP option would have been sent after the initial SYN exchange, when the TCP sender already had an estimate of the round- trip time.
The Performance Transparency Protocol: The Performance Transparency Protocol (PTP) includes a proposal for a single PTP packet that would collect information from routers along the path from the sender to the receiver [W00]. For example, a single PTP packet could be used to determine the bottleneck bandwidth along a path.
The Performance Transparency Protocol: The Performance Transparency Protocol (PTP) includes a proposal for a single PTP packet that would collect information from routers along the path from the sender to the receiver [W00]. For example, a single PTP packet could be used to determine the bottleneck bandwidth along a path.
ETEN: Additional proposals for end nodes to collect explicit information from routers include one variant of Explicit Transport Error Notification (ETEN), which includes a cumulative mechanism to notify endpoints of aggregate congestion statistics along the path [KAPS02]. (A second variant in [KSEPA04] does not depend on cumulative congestion statistics from the network.)
ETEN: エンドノードがルータから明示的な情報を集めるという追加提案はExplicit Transport Error Notification(ETEN)の1つの異形を含んでいます。(Explicit Transport Error Notificationは、経路[KAPS02]に沿って集合混雑統計の終点に通知するために累積しているメカニズムを含んでいます)。 ([KSEPA04]の2番目の異形はネットワークから累積している混雑統計によりません。)
A.4. Fast Start-Ups with more Fine-Grained Feedback from Routers
A.4。 速く、以上がすばらしく粒状でRoutersからのFeedbackをStart上げます。
Proposals for more fine-grained, congestion-related feedback from routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking [K03]. Appendix B.6 discusses in more detail the relationship between Quick-Start and proposals for more fine-grained per-packet feedback from routers.
ルータからのより多くのきめ細かに粒状の、そして、より混雑する関連のフィードバックのための提案はXCP[KHR02]、MaxNet[MaxNet]、および[K03]をマークするAntiECNを含んでいます。 付録B.6はルータからさらに詳細に1パケットあたりのきめ細かにより粒状のフィードバックのためのクィック-始めと提案との関係について議論します。
XCP: Proposals, such as XCP for new congestion control mechanisms based on more feedback from routers, are more powerful than Quick-Start, but also are more complex to understand and more difficult to deploy. XCP routers maintain no per-flow state, but provide more fine- grained feedback to end-nodes than the one-bit congestion feedback of ECN. The per-packet feedback from XCP can be positive or negative, and specifies the increase or decrease in the sender's congestion window when this packet is acknowledged. XCP is a full-fledge congestion control scheme, whereas Quick-Start represents a quick check to determine if the network path is significantly underutilized such that a connection can start faster and then fall back to TCP's standard congestion control algorithms.
XCP: ルータからの、より多くのフィードバックに基づく新しい混雑制御機構のためのXCPなどの提案は、クィック-始めより強力ですが、理解するために、より複雑であって、展開するのはまたより難しいです。 XCPルータは、1流れあたりの状態を全く維持しませんが、電子証券取引ネットワークの1ビットの混雑フィードバックよりエンドノードへのすばらしい粒状のフィードバックを提供します。 XCPからの1パケットあたりのフィードバックは、肯定しているか、または否定している場合があって、このパケットが承認されるとき、送付者の混雑ウィンドウの増加か減少を指定します。 XCPは完全に羽毛でおおっている輻輳制御計画ですが、クィック-始めは、接続がTCPの標準の輻輳制御アルゴリズムへ、より速く始まって、次に、後ろへ下がることができるようにネットワーク経路がかなりunderutilizedされるかどうか決定するために迅速なチェックを表します。
Floyd, et al. Experimental [Page 57] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[57ページ]RFC4782クィックスタートとIP2007年1月
AntiECN: The AntiECN proposal is for a single bit in the packet header that routers could set to indicate that they are underutilized. For each TCP ACK arriving at the sender indicating that a packet has been received with the Anti-ECN bit set, the sender would be able to increase its congestion window by one packet, as it would during slow-start.
AntiECN: AntiECN提案は1ビットのためにルータがそれらがunderutilizedされるのを示すように設定できたパケットのヘッダーにあります。 Anti-電子証券取引ネットワークビットがセットした状態でパケットが受け取られたのを示す送付者に到着する各TCP ACKに関しては、送付者は1つのパケットで混雑ウィンドウを増加させることができるでしょう、遅れた出発の間、そうするように。
A.5. Fast Start-Ups with Lower-Than-Best-Effort Service
A.5。 ベストエフォート型であるより低いサービスに従って、速く始動してください。
There have been proposals for routers to provide a Lower Effort differentiated service that would be lower than best effort [RFC3662]. Such a service could carry traffic for which delivery is strictly optional, or could carry traffic that is important but that has low priority in terms of time. Because it does not interfere with best-effort traffic, Lower Effort services could be used by transport protocols that start up faster than slow-start. For example, [SGF05] is a proposal for the transport sender to use low- priority traffic for much of the initial traffic, with routers configured to use strict priority queueing.
ルータがベストエフォート型[RFC3662]より低い微分されたサービスをLower Effortに供給するという提案がありました。 そのようなサービスは、配送が厳密に任意である交通を運ぶことができたか、または時間に関して重要ですが、低い優先度を持っている交通を運ぶかもしれません。 ベストエフォート型交通を妨げないので、遅れた出発より速く始動するトランスポート・プロトコルはLower Effortサービスを利用できました。 例えば、[SGF05]は輸送送付者が初期の交通の大部分に低い優先権交通を使用するという提案です、ルータが厳しい優先権待ち行列を使用するために構成にされているので。
A separate but related issue is that of below-best-effort TCP, variants of TCP that would not rely on Lower Effort services in the network, but would approximate below-best-effort traffic by detecting and responding to congestion sooner than standard TCP. TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such proposals for below-best-effort TCP, with the purpose of allowing TCP connections to use the bandwidth unused by TCP and other traffic in a non- intrusive fashion. Both TCP Nice and TCP Low Priority use the default slow-start mechanisms of TCP.
別々の、しかし、関連する問題はそうするTCPの異形が以下のベストエフォート型TCPでは、ネットワークではLower Effortサービスに依存しませんが、標準のTCPより早く混雑に検出して、応じることによって以下のベストエフォート型交通に近似するだろうということです。 TCPニース[V02]とTCP Low Priority(TCP-LP)[KK03]は以下のベストエフォート型TCPのためのそのような2つの提案です、TCP接続が非押しつけがましいやり方におけるTCPと他の交通による未使用の帯域幅を使用するのを許容する目的で。 TCPニースとTCP Low Priorityの両方がTCPのデフォルト遅れた出発メカニズムを使用します。
We note that Quick-Start is quite different from either a Lower- Effort service or a below-best-effort variant of TCP. Unlike these proposals, Quick-Start is intended to be useful for best-effort traffic that wishes to receive at least as much bandwidth as competing best-effort connections.
私たちは、クィック-始めがTCPのLower努力サービスか以下のベストエフォート型異形のどちらかと全く異なっていることに注意します。 これらの提案と異なって、クィック-始めが競争しているベストエフォート型接続として多くの帯域幅を少なくとも受け取りたがっているベストエフォート型交通の役に立つことを意図します。
Floyd, et al. Experimental [Page 58] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[58ページ]RFC4782クィックスタートとIP2007年1月
Appendix B. Design Decisions
付録B.デザイン決定
B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
B.1。 クィックスタート要求のためにメカニズムを交替してください: ICMPとRSVP
This document has proposed using an IP Option for the Quick-Start Request from the sender to the receiver, and using transport mechanisms for the Quick-Start Response from the receiver back to the sender. In this section, we discuss alternate mechanisms, and consider whether ICMP ([RFC792], [RFC4443]) or RSVP [RFC2205] protocols could be used for delivering the Quick-Start Request.
このドキュメントは、クィック-スタートRequestに送付者から受信機までIP Optionを使用して、クィック-スタートResponseに受信機から送付者まで移送機構を使用するよう提案しました。 このセクションでは、私たちは、交互のメカニズムについて論じて、クィック-スタートRequestを届けるのにICMP[RFC792]、[RFC4443)またはRSVP[RFC2205]プロトコルを使用できたかどうか考えます。
B.1.1. ICMP
B.1.1。 ICMP
Being a control protocol used between Internet nodes, one could argue that ICMP is the ideal method for requesting permission for faster start-up from routers. The ICMP header is above the IP header. Quick-Start could be accomplished with ICMP as follows: If the ICMP protocol is used to implement Quick-Start, the equivalent of the Quick-Start IP option would be carried in the ICMP header of the ICMP Quick-Start Request. The ICMP Quick-Start Request would have to pass by the routers on the path to the receiver, possibly using the IP Router Alert option [RFC2113]. A router that approves the Quick- Start Request would take the same actions as in the case with the Quick-Start IP Option, and forward the packet to the next router along the path. A router that does not approve the Quick-Start Request, even with a decreased value for the Requested Rate, would delete the ICMP Quick-Start Request, and send an ICMP Reply to the sender that the request was not approved. If the ICMP Reply was dropped in the network, and did not reach the receiver, the sender would still know that the request was not approved from the absence of feedback from the receiver. If the ICMP Quick-Start Request was dropped in the network due to congestion, the sender would assume that the request was not approved. The ICMP message would need the source and destination port numbers for demultiplexing at the end nodes. If the ICMP Quick-Start Request reached the receiver, the receiver would use transport-level or application-level mechanisms to send a response to the sender, exactly as with the IP Option.
インターネット接続装置の間で使用される制御プロトコルであり、1つは、ICMPが上にからルータから始まるように、より速い許可を要求するための理想的な方法であると主張するかもしれません。 IPヘッダーの上にICMPヘッダーがあります。 ICMPは以下の通りで迅速な始めを実行できました: ICMPプロトコルがクィック-始めを実行するのに使用されるなら、クィック-スタートIPオプションの同等物はICMPクィック-スタートRequestのICMPヘッダーで運ばれるでしょう。 ICMPクィック-スタートRequestは経路のルータのそばを受信機に通らなければならないでしょう、ことによると、IP Router Alertオプション[RFC2113]を使用して。 スタートRequestがクィック-スタートIP Optionがある場合で同じ行動を取って、パケットを送るクィックを経路に沿った次のルータに承認するルータ。 承認されて、それがするルータは、Requested Rateのために減少している値があってもクィック-スタートRequestを承認して、ICMPクィック-スタートRequestを削除して、要求は送付者へのICMP Replyでしたが、発信しないでしょう。 ICMP Replyがネットワークで落とされて、受信機に達しないなら、送付者は、要求がフィードバックの欠如から受信機から承認されなかったのをまだ知っているでしょうに。混雑のため、ICMPクィック-スタートRequestがネットワークで落とされるなら、送付者は、要求が承認されなかったと仮定するでしょうに。 ICMPメッセージはエンドノードで逆多重化のソースと仕向港番号を必要とするでしょう。 ICMPクィック-スタートRequestが受信機に達するなら、受信機は応答を送付者に送るのに輸送レベルかアプリケーションレベルメカニズムを使用するでしょうに、ちょうどIP Optionのように。
One benefit of using ICMP would be that the delivery of the TCP SYN packet or other initial packet would not be delayed by IP option processing at routers. A greater advantage is that if middleboxes were blocking packets with Quick-Start Requests, using the Quick- Start Request in a separate ICMP packet would mean that the middlebox behavior would not affect the connection as a whole. (To get this robustness to middleboxes with TCP using an IP Quick-Start Option, one would have to have a TCP-level Quick-Start Request packet that could be sent concurrently with, but separately from, the TCP SYN packet.)
ICMPを使用する1つの利益はTCP SYNパケットか他の初期のパケットの配送がルータでIPオプション処理で遅れないだろうということでしょう。 より大きい利点はmiddleboxesがクィック-スタートRequestsと共にパケットを妨げているなら、別々のICMPパケットでクィックスタートRequestを使用するのが、middleboxの振舞いが全体で接続に影響しないことを意味するだろうということです。 (TCPが別々にOption、ものが同時に送ることができるTCP-レベルクィック-スタートRequestパケットを持たなければならないIPクィック-始めを使用している状態でこの丈夫さをmiddleboxesに得る、TCP SYNパケット)。
Floyd, et al. Experimental [Page 59] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[59ページ]RFC4782クィックスタートとIP2007年1月
However, there are a number of disadvantages to using ICMP. Some firewalls and middleboxes may not forward the ICMP Quick-Start Request packets. (If an ICMP Reply packet from a router to the sender is dropped in the network, the sender would still know that the request was not approved, as stated earlier, so this would not be as serious of a problem.) In addition, it would be difficult, if not impossible, for a router in the middle of an IP tunnel to deliver an ICMP Reply packet to the actual source, for example, when the inner IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301]. Again, however, the ICMP Reply packet would not be essential to the correct operation of ICMP Quick-Start.
しかしながら、ICMPを使用することへの多くの難点があります。 いくつかのファイアウォールとmiddleboxesはICMPクィック-スタートRequestパケットを進めないかもしれません。 (ルータから送付者までのICMP Replyパケットがネットワークで落とされるなら、送付者は、要求が承認されなかったのをまだ知っているでしょう、これが問題が重大でないだろうことで、より早く述べられるとして。) さらに、ICMP Replyパケットを実際のソースに届けるのは、例えば難しいか、またはIPトンネルの中央のルータには、不可能でしょう、内側のIPヘッダーがコード化されているとき、IPsec超能力トンネルモード[RFC4301]のように。 しかしながら、一方、ICMP ReplyパケットはICMPクィック-始めの正しい操作に不可欠でないでしょう。
Unauthenticated out-of-band ICMP messages could enable some types of attacks by third-party malicious hosts that are not possible when the control information is carried in-band with the IP packets that can only be altered by the routers on the connection path. Finally, as a minor concern, using ICMP would cause a small amount of additional traffic in the network, which is not the case when using IP options.
バンドの外でUnauthenticatedされて、ICMPメッセージは制御情報が接続道のルータから変更できるだけである運ばれたIPに伴うバンドのパケットであるときに可能でない第三者悪意があるホストによる何人かのタイプの攻撃を可能にするかもしれません。 小さい方の関心として最終的にICMPを使用すると、ネットワークの少量の追加交通が引き起こされるでしょう。(IPオプションを使用するとき、ネットワークはケースではありません)。
B.1.2. RSVP
B.1.2。 RSVP
With some modifications, RSVP [RFC2205] could be used as a bearer protocol for carrying the Quick-Start Requests. Because routers are expected to process RSVP packets more extensively than the normal transport protocol IP packets, delivering a Quick-Start rate request using an RSVP packet would seem an appealing choice. However, Quick- Start with RSVP would require a few differences from the conventional usage of RSVP. Quick-Start would not require periodical refreshing of soft state, because Quick-Start does not require per-connection state in routers. Quick-Start Requests would be transmitted downstream from the sender to receiver in the RSVP Path messages, which is different from the conventional RSVP model where the reservations originate from the receiver. Furthermore, the Quick- Start Response would be sent using the transport-level or application-level mechanisms, instead of using the RSVP Resv message.
いくつかの変更で、クィック-スタートRequestsを運ぶのに、運搬人プロトコルとしてRSVP[RFC2205]を使用できました。 ルータが正常なトランスポート・プロトコルIPパケットより手広くRSVPパケットを処理すると予想されるので、RSVPパケットを使用することでクィック-スタートレート要求を提供するのは魅力的な選択に見えるでしょう。 しかしながら、RSVPとのクィック始めはRSVPの慣例的用法からいくつかの違いを必要とするでしょう。 クィック-始めがルータで1接続あたりの状態を必要としないので、迅速な始めは軟性国家の定期刊行のリフレッシュを必要としないでしょう。 その上、クィックスタートResponseに輸送レベルかアプリケーションレベルメカニズムを使用させるでしょう、RSVP Resvメッセージを使用することの代わりに。送付者から受信機まで迅速なスタートRequestsはRSVP Pathメッセージの伝えられた川下でしょう。(それは、予約が受信機から発する従来のRSVPモデルと異なっています)。
If RSVP was used for carrying a Quick-Start Request, a new "Quick- Start Request" class object would be included in the RSVP Path message that is sent from the sender to receiver. The object would contain the rate request field in addition to the common length and type fields. The Send_TTL field in the RSVP common header could be used as the equivalent of the QS TTL field. The Quick-Start capable routers along the path would inspect the Quick-Start Request object in the RSVP Path message, decrement Send_TTL, and adjust the rate request field if needed. If an RSVP router did not understand the Quick-Start Request object, it would reject the entire RSVP message and send an RSVP PathErr message back to the sender. When an RSVP message with the Quick-Start Request object reaches the receiver, the
RSVPがクィック-スタートRequestを運ぶのに使用されるなら、新しい「迅速なスタート要求」クラス物は送付者から受信機に送られるRSVP Pathメッセージに含まれているでしょうに。物は、一般的な長さに加えたレート要求分野を含んでいて、分野をタイプするでしょう。 QS TTL分野の同等物としてRSVPの一般的なヘッダーのSend_TTL分野を使用できました。 必要であるなら、経路に沿ったクィック-スタートのできるルータは、RSVP Pathメッセージでクィック-スタートRequest物を点検して、Send_TTLを減少させて、レート要求分野を調整するでしょう。 RSVPルータがクィック-スタートRequest物を理解していないなら、それは、全体のRSVPメッセージを拒絶して、RSVP PathErrメッセージを送付者に送り返すでしょうに。 クィック-スタートRequest物があるRSVPメッセージが受信機に達すると
Floyd, et al. Experimental [Page 60] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[60ページ]RFC4782クィックスタートとIP2007年1月
receiver sends a Quick-Start Reply message in the corresponding transport protocol header in the same way as described in the context of IP options earlier. If the RSVP message with the Quick-Start Request object was dropped along the path, the transport sender would simply proceed with the normal congestion control procedures.
同様に、受信機は、より早くIPオプションの文脈で説明されるように対応するトランスポート・プロトコルヘッダーでクィック-スタートReplyメッセージを送ります。 クィック-スタートRequest物があるRSVPメッセージが経路に沿って落とされるなら、輸送送付者は単に正常な輻輳制御手順を続けるでしょうに。
Much of the discussion about benefits and drawbacks of using ICMP for making the Quick-Start Request also applies to the RSVP case. If the Quick-Start Request was transmitted in a separate packet instead of as an IP option, the transport protocol packet delivery would not be delayed due to IP option processing at the routers, and the initial transport packets would reach their destination more reliably. The possible disadvantages of using ICMP and RSVP are also expected to be similar: middleboxes in the network may not be able to forward the Quick-Start Request messages, and the IP tunnels might cause problems for processing the Quick-Start Requests.
また、利益についての議論の多く、クィック-始めをRequestにするのにICMPを使用する欠点はRSVPケースに適用されます。 IPオプション処理のため、クィック-スタートRequestがIPオプションの代わりに別々のパケットで伝えられるなら、トランスポート・プロトコルパケット配信はルータで遅れないでしょうに、そして、初期の輸送パケットは、より確かに目的地に到着するでしょう。 また、ICMPとRSVPを使用する可能な損失が同様であると予想されます: ネットワークにおけるmiddleboxesはクィック-スタートRequestメッセージを転送できないかもしれません、そして、IPトンネルはクィック-スタートRequestsを処理のための問題に引き起こすかもしれません。
B.2. Alternate Encoding Functions
B.2。 機能をコード化して、交替してください。
In this section, we look at alternate encoding functions for the Rate Request field in the Quick-Start Request. The main requirements for this function is that it should have a sufficiently wide range for the requested rate. There is no need for overly fine-grained precision in the requested rate. Similarly, while it would be attractive for the encoding function to be easily computable, it is also possible for end-nodes and routers to simply store the table giving the mapping between the value N in the Rate Request field, and the actual rate request f(N). In this section, we consider possible encoding methods for Rate Request fields of different sizes, including four-bit, eight-bit, and larger Rate Request fields.
このセクションでは、私たちはクィック-スタートRequestにおけるRate Request分野のために交互のコード化機能を見ます。 この機能がそうするべきであるということであるので、主な要件には、要求されたレートのための十分広範囲があります。 きめ細かにひどく粒状の精度の必要は全く要求されたレートにありません。 同様に、コード化機能が容易に計算できるのが、魅力的でしょうが、また、エンドノードとルータがRate Request分野の値Nと、実際のレート要求f(N)の間にマッピングを与えながら単にテーブルを収納するのにおいてそれも可能です。 このセクションでは、私たちは異なったサイズのRate Request分野と可能なコード化方法を考えます、8ビット以上の4ビットのRate Request分野を含んでいて。
Linear functions: One possible proposal would be for the Rate Request field to be formatted in bits per second, scaled so that one unit equals M Kbps, for some fixed value of M. Thus, for the value N in the Rate Request field, the requested rate would be M*N Kbps.
一次関数: M.Thusの何らかの一定の価値、Rate Request分野の値Nに、提案は、Rate Request分野がbpsでフォーマットされて、スケーリングされているだろうことです、したがって、1ユニットがM Kbpsと等しいのが可能な1つ、要求されたレートはM*N Kbpsでしょう。
Powers of two: If a granularity of factors of two is sufficient for the Rate Request, then the encoding function with the most range would be for the requested rate to be K*2^N; for N, the value in the Rate Request field; and for K, some constant. For N=0, the rate request would be set to zero, regardless of the encoding function. For example, for K=40,000 and an eight-bit Rate Request field, the request range would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an unnecessarily large request range.
2人の強国: 2の要素の粒状がRate Requestに十分であるなら、要求されたレートは最も多くの範囲があるコード化機能がK*2^Nであるだろうということです。 N、Rate Request分野の値のために。 Kのための何らかの定数。 N=0において、レート要求はコード化機能にかかわらずゼロに設定されるでしょう。 例えば、K=40,000と8ビットのRate Request分野、要求範囲のために、80Kbpsから、255Kbpsが40*2^へのものでしょう。 これは明確に不必要に大きい要求範囲でしょう。
Floyd, et al. Experimental [Page 61] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[61ページ]RFC4782クィックスタートとIP2007年1月
For a four-bit Rate Request field, the upper limit on the rate request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps would be fine for the Quick-Start rate request, and that connections wishing to start up with a higher initial sending rate should be encouraged to use other mechanisms, such as the explicit reservation of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, then five or six bits could be used for the Rate Request field.
4ビットのRate Request分野に、レート要求での上限は1.3Gbpsです。 クィック-スタートレート要求に、1.3Gbpsの上限が大丈夫であるだろう、より高い初期の送付レートに従って始動したがっている接続が他のメカニズムを使用するよう奨励されるべきであるように私たちにとって思えます、帯域幅の明白な予約などのように。 1.3Gbpsの上限が許容できないなら、Rate Request分野に5ビットか6ビットを使用できるでしょうに。
The lower limit of 80 Kbps could be useful for flows with round-trip times of a second or more. For a flow with a round-trip time of one second, as is typical in some wireless networks, the TCP initial window of 4380 bytes allowed by [RFC3390] (given appropriate packet sizes) would translate to an initial sending rate of 35 Kbps. Thus, for TCP flows, a rate request of 80 Kbps could be useful for some flows with large round-trip times.
80Kbpsの下限は1秒以上の往復の回によって流れの役に立つかもしれません。 ある2番目の往復の時間がある流れのために、いくらかの無線電信がネットワークでつなぐ典型的なコネのように、[RFC3390](適切なパケットサイズを与える)によって許容された4380バイトのTCPの初期の窓は35Kbpsの初期の送付レートに翻訳されるでしょう。 したがって、TCPが流れるので80Kbpsのレート要求は大きい往復の回によっていくつかの流れの役に立つかもしれません。
The lower limit of 80 Kbps could also be useful for some non-TCP flows that send small packets, with at most one small packet every 10 ms. A rate request of 80 Kbps would translate to a rate of a hundred 100-byte packets per second (including packet headers). While some small-packet flows with large round-trip times might find a smaller rate request of 40 Kbps to be useful, our assumption is that a lower limit of 80 Kbps on the rate request will be generally sufficient. Again, if the lower limit of 80 kbps was not acceptable, then extra bits could be used for the Rate Request field.
また、80Kbpsの下限も小型小包を送るいくつかの非TCP流れの役に立つかもしれません、高々80Kbpsのあらゆる10原稿Aレート要求が1秒あたり100の100バイトのパケットのレートに翻訳するというわけではない1つの小型小包しか(パケットのヘッダーを含んでいて)。 大きい往復の回があるいくつかの小型小包流れが40Kbpsが役に立つというより小さいレート要求を見つけるかもしれませんが、私たちの仮定は一般に、レート要求での80Kbpsの下限が十分であるということです。 一方、80キロビット毎秒の下限が許容できないなら、Rate Request分野に余分なビットを使用できるでしょうに。
If the granularity of factors of two was too coarse, then the encoding function could use a base less than two. An alternate form for the encoding function would be to use a hybrid of linear and exponential functions.
2の要素の粒状が粗過ぎるなら、コード化機能は2未満のベースを使用するかもしれないでしょうに。 コード化機能のための交互のフォームは直線的で指数の機能のハイブリッドを使用するだろうことです。
A mantissa and exponent representation: Section 4.4 of [B05] suggests a mantissa and exponent representation for the Quick-Start encoding function. With e and f as the binary numbers in the exponent and mantissa fields, and with 0 <= f < 1, this would represent the rate (1+f)*2^e. [B05] suggests a mantissa field for f of 8, 16, or 24 bits, with an exponent field for e of 8 bits. This representation would allow larger rate requests, with an encoding that is less coarse than the powers-of-two encoding used in this document.
仮数と解説者表現: [B05]のセクション4.4は、機能をコード化しながら、クィック-始めの仮数と解説者表現を示します。 解説者と仮数分野の2進の数としてのeとf、およびf0<=<1で、これはレート(1+f)*2^eを表すでしょう。 [B05]は8ビットか16ビットか24ビットのfのために仮数分野を示します、8ビットのeのための解説者分野で。 この表現は、より大きいレート要求を許すでしょう、コード化が本書では使用した2人の強国ほど粗くないコード化で。
Constraints of the transport protocol: We note that the Rate Request is also constrained by the abilities of the transport protocol. For example, for TCP with Window Scaling, the maximum window is at most 2**30 bytes. For a TCP connection with a long, 1 second round-trip time, this would give a maximum sending rate of 1.07 Gbps.
輸送の規制は議定書を作ります: 私たちは、また、Rate Requestがトランスポート・プロトコルの能力によって抑制されることに注意します。 例えば、Window ScalingとTCPに関して、最大の窓は高々30バイト2**です。 長くて、1秒の往復の時間とのTCP関係のために、これは1.07Gbpsの最大の送付レートを与えるでしょう。
Floyd, et al. Experimental [Page 62] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[62ページ]RFC4782クィックスタートとIP2007年1月
B.3. The Quick-Start Request: Packets or Bytes?
B.3。 クィックスタート要求: パケットですかそれともバイトですか?
One of the design questions is whether the Rate Request field should be in bytes per second or in packets per second. We discuss this separately from the perspective of the transport, and from the perspective of the router.
デザイン質問の1つはRate Request分野が1秒あたりのバイトか1秒あたりのパケットにあるべきであるということです。 私たちは別々に輸送の見解と、ルータの見解からこれについて議論します。
For TCP, the results from the Quick-Start Request are translated into a congestion window in bytes, using the measured round-trip time and the MSS. This window applies only to the bytes of data payload, and does not include the bytes in the TCP or IP packet headers. Other transport protocols would conceivably use the Quick-Start Request directly in packets per second, or could translate the Quick-Start Request to a congestion window in packets.
TCPに関しては、クィック-スタートRequestからの結果はバイトで混雑ウィンドウに移されます、測定往復の時間とMSSを費やして。 この窓は、データペイロードのバイトだけに適用して、TCPかIPパケットのヘッダーでバイトを含めません。 他のトランスポート・プロトコルは、多分直接1秒あたりのパケットでクィック-スタートRequestを使用するだろうか、またはパケットでクィック-スタートRequestを混雑ウィンドウに移すかもしれません。
The assumption of this document is that the router only approves the Quick-Start Request when the output link is significantly underutilized. For this, the router could measure the available bandwidth in bytes per second, or could convert between packets and bytes by some mechanism.
このドキュメントの仮定は出力リンクがかなりunderutilizedされるとルータがクィック-スタートRequestを承認するだけであるということです。 これに関しては、ルータは秒あたりのバイトで利用可能な帯域幅を測定できるだろう、だろう、だろう、だろう、だろう、だろう、だろうか、パケットとバイトでいくつかのメカニズムで変換されることができました。
If the Quick-Start Request was in bytes per second, and applied only to the data payload, then the router would have to convert from bytes per second of data payload, to bytes per second of packets on the wire. If the Rate Request field was in bytes per second, and the sender ended up using very small packets, this could translate to a significantly larger number in terms of bytes per second on the wire. Therefore, for a Quick-Start Request in bytes per second, it makes most sense for this to include the transport and IP headers as well as the data payload. Of course, this will be, at best, a rough approximation on the part of the sender; the transport-level sender might not know the size of the transport and IP headers in bytes, and might know nothing at all about the separate headers added in IP tunnels downstream. This rough estimate seems sufficient, however, given the overall lack of fine precision in Quick-Start functionality.
クィック-スタートRequestが1秒あたりのバイトであって、データペイロードだけに適用されているなら、ルータはデータペイロードの秒あたりのバイトから変えなければならないでしょう、ワイヤの上のパケットの秒あたりのバイトに。 Rate Request分野が1秒あたりのバイトであって、送付者が結局非常に小さいパケットを使用するなら、これはワイヤの上に1秒あたりのバイトに関してかなり大きい数に翻訳されることができるでしょうに。 したがって、1秒あたりのバイトで表現される、クィック-スタートRequestに関して、それはこれが輸送とIPを含む意味にデータペイロードと同様にヘッダーに最もなります。 もちろん、これは送付者側のせいぜい概算になるでしょう。 輸送レベル送付者は、バイトで表現される輸送とIPヘッダーのサイズを知らないで、全く別々のヘッダーに関する何も川下でIPトンネルを加えなかったのを知るかもしれません。 しかしながら、クィック-スタートの機能性における、すばらしい精度の総合的な不足を考えて、この概算は十分に見えます。
It has been suggested that the router could possibly use information from the MSS option in the TCP packet header of the SYN packet to convert the Quick-Start Request from packets per second to bytes per second, or vice versa. This would be problematic for several reasons. First, if IPsec is used, the TCP header will be encrypted. Second, the MSS option is defined as the maximum MSS that the TCP sender expects to receive, not the maximum MSS that the TCP sender plans to send [RFC793]. However, it is probably often the case that this MSS also applies as an upper bound on the MSS used by the TCP sender in sending.
ルータが1秒あたり1秒あたりのパケットからバイトまでクィック-スタートRequestを変換するのにSYNパケットのTCPパケットのヘッダーでMSSオプションから情報を使用できたことが提案されたか、逆もまた同様です。 これはいくつかの理由で問題が多いでしょう。 まず最初に、IPsecが使用されていると、TCPヘッダーはコード化されるでしょう。 2番目に、MSSオプションはTCP送付者が送るのを計画している最大のMSS[RFC793]ではなく、TCP送付者が受け取ると予想する最大のMSSと定義されます。 しかしながら、しばしばまた、このMSSが上限として発信にTCP送付者によって使用されたMSSに適用するのは、たぶん事実です。
Floyd, et al. Experimental [Page 63] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[63ページ]RFC4782クィックスタートとIP2007年1月
We note that the sender does not necessarily know the Path MTU when the Quick-Start Request is sent, or when the initial window of data is sent. Thus, with IPv4, packets from the initial window could end up being fragmented in the network if the "Don't Fragment" (DF) bit is not set [RFC1191]. A Rate Request in bytes per second is reasonably robust to fragmentation. Clearly, a Rate Request in packets per second is less robust in the presence of fragmentation. Interactions between larger initial windows and Path MTU Discovery are discussed in more detail in RFC 3390 [RFC3390].
私たちは、クィック-スタートRequestを送るか、またはデータの初期の窓を送るとき、送付者が必ずPath MTUを知っているというわけではないことに注意します。 したがって、「断片化しないでください」という(DF)ビットが設定されないなら[RFC1191]、IPv4に、結局、初期の窓からのパケットによってネットワークで断片化されるかもしれません。 1秒あたりのバイトで表現されるRate Requestは合理的に断片化に強健です。 明確に、1秒あたりのパケットのRate Requestは断片化があるとき強健ではありません。 さらに詳細にRFC3390[RFC3390]で、より大きい初期の窓とPath MTUディスカバリーとの相互作用について議論します。
For a Quick-Start Request in bytes per second, the transport senders would have the additional complication of estimating the bandwidth usage added by the packet headers.
1秒あたりのバイトで表現される、クィック-スタートRequestに関して、輸送送付者はパケットのヘッダーに帯域幅が用法であると見積もる追加複雑さを加えさせるでしょう。
We have chosen a Rate Request field in bytes per second rather than in packets per second because it seems somewhat more robust, particularly to routers.
それがいくらか強健に見えるので、私たちは1秒単位でパケットでというよりむしろ秒あたりのバイトで表現されるRate Request分野を選びました、特にルータに。
B.4. Quick-Start Semantics: Total Rate or Additional Rate?
B.4。 クィックスタート意味論: 総レートですかそれとも割増運賃ですか?
For a Quick-Start Request sent in the middle of a connection, there are two possible semantics for the Rate Request field, as follows:
接続の途中で送られたクィック-スタートRequestのために、Rate Request分野への2の可能な意味論があります、以下の通りです:
(1) Total Rate: The requested Rate Request is the requested total
rate for the connection, including the current rate; or
(1) レートを合計してください: 要求されたRate Requestは成り行き相場を含む接続の要求された総速度です。 または
(2) Additional Rate: The requested Rate Request is the requested
increase in the total rate for that connection, over and above
the current sending rate.
(2) 割増運賃: その接続の総速度とレートと現在の送付レートより上で要求されたRate Requestは要求された増加です。
When the Quick-Start Request is sent after an idle period, the current sending rate is zero, and there is no difference between (1) and (2) above. However, a Quick-Start Request can also be sent in the middle of a connection that has not been idle, e.g., after a mobility event, or after an application-limited period when the sender is suddenly ready to send at a much higher rate. In this case, there can be a significant difference between (1) and (2) above. In this section, we consider briefly the tradeoffs between these two options, and explain why we have chosen the `Total Rate' semantics.
活動していない期間の後にクィック-スタートRequestを送るとき、現在の送付レートはゼロです、そして、違いが全く上に(1)と(2)の間にありません。 しかしながら、クィック-スタートRequestはまた、例えば、移動性出来事の後に無駄でない接続の途中で送る準備ができることができるか、または突然、送付者であることのアプリケーション限定期間の後にはるかに高いレートで発信する準備ができています。 この場合、著しい違いが上に(1)と(2)の間にあることができます。 このセクションで、私たちは、簡潔にこれらの2つのオプションの間の見返りを考えて、なぜ'総Rate'意味論を選んだかを説明します。
The Total Rate semantics makes it easier for routers to "allocate" the same rate to all connections. This lends itself to fairness, and improves convergence times between old and new connections. With the Additional Rate semantics, the router would not necessarily know the current sending rates of the flows requesting additional rates, and therefore would not have sufficient information to use fairness as a metric in granting rate requests. With the Total Rate semantics, the
Total Rate意味論で、ルータがすべての接続に同じレートを「割り当て」であることが、より簡単になります。 これは、公正に適して、古くて新しい接続の間で集合時間を改良します。 Additional Rate意味論によって、ルータは、必ず割増運賃を要求する流れの現在の送付速度を知っているというわけではなくて、したがって、レート要求を承諾しながらメートル法のコネとして公正を使用できるくらいの情報を持っていないでしょう。 Total Rate意味論で
Floyd, et al. Experimental [Page 64] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[64ページ]RFC4782クィックスタートとIP2007年1月
fairness is automatic; the router is not granting rate requests for *additional* bandwidth without knowing the current sending rates of the different flows.
公正は自動です。 異なった流れの現在の送付速度を知らないで、ルータは*追加*帯域幅を求めるレート要求を承諾していません。
The Additional Rate semantics also lends itself to gaming by the connection, with senders sending frequent Quick-Start Requests in the hope of gaining a higher rate. If the router is granting the same maximum rate for all rate requests, then there is little benefit to a connection of sending a rate request over and over again. However, if the router is granting an *additional* rate with each rate request, over and above the current sending rate, then it is in a connection's interest to send as many rate requests as possible, even if very few of them are, in fact, granted.
また、Additional Rate意味論は接続で勝負事をするのにそれ自体を与えます、より高いレートを獲得することを希望した頻繁なクィック-スタートRequestsを送付者による送付で。 ルータがすべてのレート要求のための同じ最高率を与えているなら、レート要求を幾重にも送る接続への利益がほとんどありません。 しかしながら、ルータがそれぞれのレート要求てレートと現在の送付レートより高い*追加*レートを与えているなら、できるだけ多くのレート要求を送るために、接続の利益のためにはそれがあります、事実上それらのほんのわずかを与えても。
Appendix E discusses a Report of Current Sending Rate as one possible function in the Quick-Start Option. However, we have not standardized this possible use at this time.
付録Eはクィック-スタートOptionにおける1つの可能な機能としてCurrent Sending RateのReportについて議論します。 しかしながら、私たちはこのとき、この活用可能性を標準化していません。
B.5. Alternate Responses to the Loss of a Quick-Start Packet
B.5。 クィックスタートパケットの損失への交互の応答
Section 4.6 discusses TCP's response to the loss of a Quick-Start packet in the initial window. This section discusses several alternate responses.
セクション4.6は初期の窓のクィック-スタートパケットの損失へのTCPの応答について論じます。 このセクションはいくつかの交互の応答について論じます。
One possible alternative to reverting to the default Slow-Start after the loss of a Quick-Start packet from the initial window would have been to halve the congestion window and continue in congestion avoidance. However, we note that this would not have been a desirable response for either the connection or for the network as a whole. The packet loss in the initial window indicates that Quick- Start failed in finding an appropriate congestion window, meaning that the congestion window after halving may easily also be wrong.
クィック-スタートパケットの損失の後に初期の窓からデフォルトSlow-始めに戻ることへの1つの可能な選択肢が、混雑ウィンドウを半分にして、輻輳回避で続くことになっていたでしょう。 しかしながら、私たちは、これが接続か全体でネットワークに、望ましい応答でないことに注意します。 初期の窓のパケット損失は、クィック始めが適切な混雑ウィンドウを見つける際に失敗したのを示します、また、半分にの後の混雑ウィンドウも容易に間違うかもしれないことを意味して。
A more moderate alternate would be to continue in congestion avoidance from a window of (W-D)/2, where W is the Quick-Start congestion window, and D is the number of packets dropped or marked from that window. However, such an approach would implicitly assume that the number of Quick-Start packets delivered is a good indication of the appropriate available bandwidth for that flow, even though other packets from that window were dropped in the network. And, further, that using half the number of segments that were successfully transmitted is conservative enough to account for the possibly inaccurate congestion window indication. We believe that such an assumption would require more analysis at this point, particularly in a network with a range of packet dropping mechanisms at the router, and we cannot recommend it at this time.
より適度の補欠は(W-D)/2の窓から輻輳回避で続くことになっているでしょう。(そこでは、Wがクィック-スタート混雑ウィンドウであり、Dはその窓から落とされたか、またはマークされたパケットの数です)。 しかしながら、そのようなアプローチは、パケットが提供したクィック-始めの数がその流れのための適切な利用可能な帯域幅の良いしるしであるとそれとなく仮定するでしょう、その窓からの他のパケットがネットワークで落とされましたが。 そして、さらに、セグメントの半数を使用して、それが首尾よく伝えられたのは、ことによると不正確な混雑窓の指示を説明できるくらい保守的です。 私たちは、そのような仮定がここにより多くの分析を必要とすると信じています、特にさまざまなパケットがルータでメカニズムを落としているネットワークで、そして、私たちがこのとき、それを推薦できません。
Floyd, et al. Experimental [Page 65] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[65ページ]RFC4782クィックスタートとIP2007年1月
Another drawback of approaches that don't revert back to slow-start when a Quick-Start packet in the initial window is dropped is that such approaches could give the TCP receiver a greater incentive to lie about the Quick-Start Request. If the sender reverts to slow- start when a Quick-Start packet in the initial window is dropped, this diminishes the benefit a receiver would get from a Quick-Start request that resulted in a dropped or ECN-marked packet.
初期の窓のクィック-スタートパケットが落とされるとき遅れた出発に戻って戻らないアプローチの別の欠点はそのようなアプローチがクィック-スタートRequestに関して嘘をつくよりすばらしい誘因をTCP受信機に与えるかもしれないということです。 初期の窓のクィック-スタートパケットが落とされるとき、遅くする送付者復帰者が始めるなら、これは受信機が低下したか電子証券取引ネットワークが著しいパケットをもたらしたクィック-スタート要求から得る利益を減少させます。
B.6. Why Not Include More Functionality?
B.6。 なぜより多くの機能性を含んでいませんか?
This proposal for Quick-Start is a rather coarse-grained mechanism that would allow a connection to use a higher sending rate along underutilized paths, but that does not attempt to provide a next- generation transport protocol or congestion control mechanism, and does not attempt the goal of providing very high throughput with very low delay. Appendix A.4 discusses a number of proposals (such as XCP, MaxNet, and AntiECN) that provide more fine-grained per-packet feedback from routers than the current congestion control mechanisms and that attempt these more ambitious goals.
クィック-始めのためのこの提案は接続がunderutilized経路に沿って、より高い送付レートを使用するのを許容しますが、次の世代トランスポート・プロトコルか混雑制御機構を提供するのを試みないで、また非常に低い遅れを非常に高いスループットに提供するという目標を試みないかなり下品なメカニズムです。 付録A.4はルータからの現在の混雑制御機構とそれがこれらのより野心満々の目標を試みるよりきめ細かに粒状の1パケットあたりのフィードバックを提供する多くの提案(XCPや、MaxNetや、AntiECNなどの)について議論します。
Compared to proposals such as XCP and AntiECN, Quick-Start offers much less control. Quick-Start does not attempt to provide a new congestion control mechanism, but simply to get permission from routers for a higher sending rate at start-up, or after an idle period. Quick-Start can be thought of as an "anti-congestion- control" mechanism that is only of any use when all the routers along the path are significantly underutilized. Thus, Quick-Start is of no use towards a target of high link utilization, or fairness in a high-utilization scenario, or controlling queueing delay during high utilization, or anything of the like.
XCPやAntiECNなどの提案と比べて、まして、クィック-始めはコントロールを提供します。 迅速な始めは、単に上にから始まることにおいて、活動していない期間の後により高い送付レートのためにルータから許可を得るためにしかし、新しい混雑制御機構を提供するのを試みません。 経路に沿ったすべてのルータがかなりunderutilizedされるとき単にいずれ役に立つ「反混雑しているコントロール」のメカニズムとして迅速な始めを考えることができます。 したがって、クィック-始めは、高いリンク利用の目標、または高使用率シナリオの公正に向かって無駄であるか、または高使用率、または同様のものについて何かの間、待ち行列遅れを制御します。
At the same time, Quick-Start would allow larger initial windows than would proposals such as AntiECN, requires less input to routers than XCP (e.g., XCP's cwnd and RTT fields), and would require less frequent feedback from routers than any new congestion control mechanism. Thus, Quick-Start is significantly less powerful than proposals for new congestion control mechanisms, such as XCP and AntiECN, but as powerful or more powerful in terms of the specific issue of allowing larger initial windows. Also, (we think) it is more amenable to incremental deployment in the current Internet.
同時にクィック-始めが、より大きい初期の窓を許容するだろう、AntiECNなどの提案、ルータへの入力よりXCP(例えば、XCPのcwndとRTT分野)を必要として、ルータからの頻繁なフィードバックより新しい混雑制御機構を必要とするでしょう。 したがって、クィック-始めは提案よりかなりXCPやAntiECNなどの新しい混雑制御機構に強力であるのではなく、より大きい初期の窓を許容する特定の問題で強力であるか、より強力であるとして強力です。 また、(私たちは考えます)それも現在のインターネットでの増加の展開により従順です。
We do not discuss proposals such as XCP in detail, but simply note that there are a number of open questions. One question concerns whether there is a pressing need for more sophisticated congestion control mechanisms, such as XCP, in the Internet. Quick-Start is inherently a rather crude tool that does not deliver assurances about maintaining high link utilization and low queueing delay; Quick-Start is designed for use in environments that are significantly
私たちは詳細にXCPなどの提案について議論しませんが、多くの未決問題があることに単に注意してください。 より洗練された混雑のための差し迫った必要性があるか否かに関係なく、1回の質問関心がメカニズムを制御します、XCPなどのように、インターネットで。 本来迅速な始めは高いリンク利用と低い待ち行列遅れを維持することに関して保証を提供しないかなり粗雑なツールです。 迅速な始めはかなり、そうである環境における使用のために設計されています。
Floyd, et al. Experimental [Page 66] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[66ページ]RFC4782クィックスタートとIP2007年1月
underutilized, and addresses the single question of whether a higher sending rate is allowed. New congestion control mechanisms with more fine-grained feedback from routers could allow faster start-ups even in environments with rather high link utilization. Is this a pressing requirement? Are the other benefits of more fine-grained congestion control feedback from routers a pressing requirement?
より高い送付レートが許容されているかどうかに関するただ一つの質問をunderutilizedして、記述します。 ルータからのきめ細かにより粒状のフィードバックがある新しい混雑制御機構は環境さえにおけるかなり高いリンク利用による、より速い始動を許すかもしれません。 これは緊急の要件ですか? ルータからのきめ細かにより粒状の輻輳制御フィードバックの諸手当は緊急の要件ですか?
We would argue that even if more fine-grained per-packet feedback from routers was implemented, it is reasonable to have a separate mechanism, such as Quick-Start, for indicating an allowed initial sending rate, or an allowed total sending rate after an idle or underutilized period.
私たちは、ルータからの1パケットあたりのきめ細かにより粒状のフィードバックが実行されたとしても、別々のメカニズムを持っているのが妥当であると主張するでしょう、クィック-始めなどのように、活動していないかunderutilizedされた期間の後に許容初期の送付レート、または許容総送付レートを示すために。
One difference between Quick-Start and current proposals for fine- grained per-packet feedback, such as XCP, is that XCP is designed to give robust performance even in the case where different packets within a connection routinely follow different paths. XCP achieves relatively robust performance in the presence of multipath routing by using per-packet feedback, where the feedback carried in a single packet is about the relative increase or decrease in the rate or window to take effect when that particular packet is acknowledged, not about the allowed sending rate for the connection as a whole.
クィック-始めとXCPなどの1パケットあたりのすばらしい粒状のフィードバックのための現在の提案の1つの違いはXCPが接続の中の異なったパケットがきまりきって異なった経路に続く場合でさえロバスト性能を与えるように設計されているということです。 XCPは、全体で接続の許容送付速度で達成するのではなく、多重通路ルーティングがあるとき1パケットあたりのフィードバックを使用することによって、比較的体力を要している性能を達成します。(そこでは、単一のパケットで運ばれたフィードバックが、その特定のパケットが承認されるとき、効くためにはレートか窓の相対的増加か減少に関するものです)。
In contrast, Quick-Start sends a single Quick-Start Request, and the answer to that request gives the allowed sending rate for an entire window of data. As a result, Quick-Start could be problematic in an environment where some fraction of the packets in a window of data take path A, and the rest of the packets take path B; for example, the Quick-Start Request could have traveled on path A, while half the Quick-Start packets sent in the succeeding round-trip time are routed on path B. We note that [ZDPS01] shows Internet paths to be stable on the order of RTTs.
対照的に、クィック-始めは独身のクィック-スタートRequestを送ります、そして、その要求の答えはデータの全体の窓の許容送付料金を与えます。 その結果、クィック-始めはデータの窓のパケットのある部分が経路Aを取るところで環境で問題が多いかもしれません、そして、パケットの残りは経路Bを取ります。 例えば、クィック-スタートRequestは経路Aを旅行したかもしれません、クィック-スタートパケットが続く往復の時間で送った半分が[ZDPS01]が、インターネット経路がRTTsの注文のときに安定しているのを示すという経路B.Weメモの上に発送されますが。
There are also differences between Quick-Start and some of the proposals for per-packet feedback in terms of the number of bits of feedback required from the routers to the end-nodes. Quick-Start uses four bits of feedback in the rate request field to indicate the allowed sending rate. XCP allocates a byte for per-packet feedback, though there has been discussion of variants of XCP with less per- packet feedback. This would be more like other proposals, such as anti-ECN, that use a single bit of feedback from routers to indicate that the sender can increase as fast as slow-starting, in response to this particular packet acknowledgement. In general, there is probably considerable power in fine-grained proposals with only two bits of feedback, indicating that the sender should decrease, maintain, or increase the sending rate or window when this packet is acknowledged. However, the power of Quick-Start would be considerably limited if it was restricted to only two bits of
提案のクィック-始めといくつかの間には、ルータからエンドノードまで必要であるフィードバックのビットの数に関して違いも1パケットあたりのフィードバックのためにあります。 迅速な始めは、許容送付レートを示すのにレート要求分野のフィードバックの4ビットを使用します。 XCPは1パケットあたりのフィードバックのために1バイトを割り当てます、以下とのXCPの異形の議論がありましたが-、パケットフィードバック。 これはさらに他の提案に似ているでしょう、反電子証券取引ネットワークなどのように、シングルが噛み付いた示す送付者が遅く始めであるのと同じくらい速く増加させることができるルータからのフィードバックのその使用、この特定のパケット承認に対応して。 一般に、フィードバックの2ビットだけによるきめ細かに粒状の提案にはかなりのパワーがたぶんあります、このパケットが承認されるとき、送付者が送付レートか窓を減少するべきであるか、維持するべきであるか、または増加させるべきであるのを示して。 しかしながら、それが2ビットだけに制限されるなら、クィック-始めのパワーはかなり限られるでしょうに。
Floyd, et al. Experimental [Page 67] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[67ページ]RFC4782クィックスタートとIP2007年1月
feedback; it seems likely that determining the initial sending rate fundamentally requires more bits of feedback from routers than does the steady-state, per-packet feedback to increase or decrease the sending rate.
フィードバック。 基本的に初期の送付レートを測定するのはルータからのフィードバックの定常状態をするより多くのビットを必要としそうです、送付レートを増加するか、または減少させる1パケットあたりのフィードバック。
On a more practical level, one difference between Quick-Start and proposals for per-packet feedback is that there are fewer open issues with Quick-Start than there would be with a new congestion control mechanism. Because Quick-Start is a mechanism for requesting an initial sending rate in an underutilized environment, its fairness issues are less severe than those of a general congestion control mechanism. With Quick-Start, there is no need for the end nodes to tell the routers the round-trip time and congestion window, as is done in XCP; all that is needed is for the end nodes to report the requested sending rate.
より実用的なレベルに関して、1パケットあたりのフィードバックのためのクィック-始めと提案の1つの違いはクィック-始めには新しい混雑制御機構であるだろうより少ない未解決の問題があるということです。 クィック-始めがunderutilized環境で初期の送付レートを要求するためのメカニズムであるので、公正問題は一般的な混雑制御機構のものほど厳しくはありません。 クィック-始めと共に、エンドノードがそのままな往復の時間と混雑ウィンドウをルータにXCPでしていた状態で言う必要は全くありません。 必要であるのはエンドノードが要求された送付レートを報告するだけであることです。
Table 3 provides a summary of the differences between Quick-Start and proposals for per-packet congestion control feedback.
テーブル3は1パケットあたりの輻輳制御フィードバックのためのクィック-始めと提案の間の違いの概要を提供します。
Proposals for
Quick-Start Per-Packet Feedback
+------------------+----------------------+----------------------+
Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet.
+------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement.
congestion ctrl: | |
+------------------+----------------------+----------------------+
Frequency: | Start-up, or after | Every packet.
| an idle period. |
+------------------+----------------------+----------------------+
Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism.
+------------------+----------------------+----------------------+
Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN).
+------------------+----------------------+----------------------+
Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice?
+------------------+----------------------+----------------------+
1パケットあたりのクィックスタートフィードバック+のための提案------------------+----------------------+----------------------+ 意味論: | 許容送付レート| レート/窓で変化してください。| 接続単位で。 | パケット単位で。 +------------------+----------------------+----------------------+ 関係| さらに。 | 交換混雑ctrl: | | +------------------+----------------------+----------------------+ 頻度: | 後に始動してください。| あらゆるパケット。 | 活動していない期間。 | +------------------+----------------------+----------------------+ 制限: | 役に立つだけ| 一般混雑| underutilized経路| メカニズムを制御してください。 +------------------+----------------------+----------------------+ ルータへの入力: | 要求を評定してください。 |RTT(cwnd)は(XCP)を要求します。| | (反電子証券取引ネットワーク)でないなにも。 +------------------+----------------------+----------------------+ フィードバックのビット: | 4ビット| 数ビットはそうするでしょう。| 要求を評定してください。 | 十分ですか? +------------------+----------------------+----------------------+
Table 3: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback.
テーブル3: 1パケットあたりのきめ細かに粒状のフィードバックのためのクィックスタートと提案の違い。
A separate question concerns whether mechanisms, such as Quick-Start, in combination with HighSpeed TCP and other changes in progress, would make a significant contribution towards meeting some of these needs for new congestion control mechanisms. This could be viewed as
メカニズムで、クィック-始めとしてあれほどか否かに関係なく、メカニズムこれを見なすことができた新しい輻輳制御のこれらのいくつかの需要を満たすことに向かって関心が進行中のHighSpeed TCPと他の変化と組み合わせて力を発揮するだろうという別々の問題
Floyd, et al. Experimental [Page 68] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[68ページ]RFC4782クィックスタートとIP2007年1月
a positive step towards meeting some of the more pressing current needs with a simple and reasonably deployable mechanism, or alternately, as a negative step of unnecessarily delaying more fundamental changes. Without answering this question, we would note that our own approach tends to favor the incremental deployment of relatively simple mechanisms, as long as the simple mechanisms are not short-term hacks, but mechanisms that lead the overall architecture in the fundamentally correct direction.
簡単で合理的に配備可能なメカニズムでいくつかの、より緊急の現在の需要を満たすことに向かった積極的なステップ、または交互に、不必要にさらに延着する否定的ステップとして、原理は変化します。 この質問に答えないで、私たちは、私たち自身のアプローチが、比較的簡単なメカニズムの増加の展開を支持する傾向があることに注意するでしょう、簡単なメカニズムが短期的なハッキングではなく、総合的な構造を基本的に正しい方向に導くメカニズムである限り。
B.7. Alternate Implementations for a Quick-Start Nonce
B.7。 クィックスタート一回だけのための交互の実現
B.7.1. An Alternate Proposal for the Quick-Start Nonce
B.7.1。 クィックスタート一回だけのための交互の提案
An alternate proposal for the Quick-Start Nonce from [B05] would be for an n-bit field for the QS Nonce, with the sender generating a random nonce when it generates a Quick-Start Request. Each router that reduces the Rate Request by r would hash the QS nonce r times, using a one-way hash function such as MD5 [RFC1321] or the secure hash 1 [SHA1]. The receiver returns the QS nonce to the sender. Because the sender knows the original value for the nonce, and the original rate request, the sender knows the total number of steps s that the rate has been reduced. The sender then hashes the original nonce s times to check whether the result is the same as the nonce returned by the receiver.
QS Nonceのためのn-ビット分野には[B05]からのクィック-スタートNonceへの交互の提案があるでしょう、クィック-スタートRequestを発生させると送付者が無作為の一回だけを発生させている状態で。 rでRate Requestを減少させる各ルータがQSの一回だけのr回数を論じ尽くすでしょう、MD5などの片道ハッシュ関数[RFC1321]か安全な細切れ肉料理1[SHA1]を使用して。 受信機はQS一回だけを送付者に返します。 送付者が知っているので、一回だけ、およびオリジナルのレート要求、送付者のための値が総数を知っているオリジナルは減少していた状態でレートがあったsを踏みます。 そして、一回だけが受信機で戻ったとき、送付者は結果が同じであるか否かに関係なく、チェックするオリジナルの一回だけのs回を論じ尽くします。
This alternate proposal for the nonce would be considerably more powerful than the QS nonce described in Section 3.4, but it would also require more CPU cycles from the routers when they reduce a Quick-Start Request, and from the sender in verifying the nonce returned by the receiver. As reported in [B05], routers could protect themselves from processor exhaustion attacks by limiting the rate at which they will approve reductions of Quick-Start Requests.
また、クィック-スタートRequestを減少させると、ルータからの、より多くのCPUサイクルを必要とするでしょう、そして、一回だけのためのこの交互の提案はセクション3.4で説明されたQS一回だけよりかなり強力でしょうが、検証における送付者から、一回だけは受信機で戻りました。[B05]で報告されるように、ルータはプロセッサ疲労困憊攻撃から彼らがクィック-スタートRequestsの減少を承認するレートを制限することによって、我が身をかばうことができるでしょう。
Both the Function field and the Reserved field in the Quick-Start Option would allow the extension of Quick-Start to use Quick-Start requests with the alternate proposal for the Quick-Start Nonce, if it was ever desired.
クィック-スタートOptionにおける、Function分野とReserved分野の両方で、クィック-始めの拡大はクィック-スタートNonceに交互の提案によるクィック-スタート要求を使用できるでしょう、それが今までに望まれていたなら。
B.7.2. The Earlier Request-Approved Quick-Start Nonce
B.7.2。 以前の要求で承認されたクィックスタート一回だけ
An earlier version of this document included a Request-Approved Quick-Start Nonce (QS Nonce) that was initialized by the sender to a non-zero, `random' eight-bit number, along with a QS TTL that was initialized to the same value as the TTL in the IP header. The Request-Approved Quick-Start Nonce would have been returned by the transport receiver to the transport sender in the Quick-Start Response. A router could deny the Quick-Start Request by failing to decrement the QS TTL field, by zeroing the QS Nonce field, or by
このドキュメントの以前のバージョンは送付者によって8ビットの非ゼロの、そして、'無作為'の数に初期化されたRequestによって承認されたクィック-スタートNonce(QS Nonce)を含んでいました、IPヘッダーでTTLと同じ値に初期化されたQS TTLと共に。 輸送受信機はRequestによって承認されたクィック-スタートNonceをクィック-スタートResponseにおける輸送送付者に返したでしょう。 ルータはQS TTL分野を減少させないことによって、クィック-スタートRequestを否定するかもしれません、QS Nonce分野のゼロを合わせることによって
Floyd, et al. Experimental [Page 69] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[69ページ]RFC4782クィックスタートとIP2007年1月
deleting the Quick-Start Request from the packet header. The QS Nonce was included to provide some protection against broken downstream routers, or against misbehaving TCP receivers that might be inclined to lie about whether the Rate Request was approved. This protection is now provided by the QS Nonce, by the use of a random initial value for the QS TTL field, and by Quick-Start-capable routers hopefully either deleting the Quick-Start Option or zeroing the QS TTL and QS Nonce fields when they deny a request.
パケットのヘッダーからクィック-スタートRequestを削除します。 QS Nonceは、壊れている川下のルータに対する、または、Rate Requestが承認されたか否かに関係なく、ころがっている傾向があるかもしれないふらちな事をしているTCP受信機に対する何らかの保護を提供するために含まれていました。 この保護は現在QS Nonceによって提供されます、QS TTL分野、および彼らが要求を否定するとき希望をいだいてクィック-スタートOptionを削除するか、またはQS TTLとQS Nonce分野のゼロに合っているできるクィックStartルータによる無作為の初期の値の使用で。
With the old Request-Approved Quick-Start Nonce, along with the QS TTL field set to the same value as the TTL field in the IP header, the Quick-Start Request mechanism would have been self-terminating; the Quick-Start Request would terminate at the first participating router after a non-participating router had been encountered on the path. This minimizes unnecessary overhead incurred by routers because of option processing for the Quick-Start Request. In the current specification, this "self-terminating" property is provided by Quick-Start-capable routers hopefully either deleting the Quick- Start Option or zeroing the Rate Request field when they deny a request. Because the current specification uses a random initial value for the QS TTL, Quick-Start-capable routers can't tell if the Quick-Start Request is invalid because of non-Quick-Start-capable routers upstream. This is the cost of using a design that makes it difficult for the receiver to cheat about the value of the QS TTL.
古いRequestによって承認されたクィック-スタートNonceで、IPヘッダーのTTL分野と同じ値に設定されたQS TTL分野と共にクィック-スタートRequestメカニズムは自己に終わっていたでしょう。 非参加ルータが経路で遭遇した後に、クィック-スタートRequestは最初の参加ルータで終わるでしょう。 これはオプション処理のためにルータによってクィック-スタートRequestへ被られた不要なオーバーヘッドを最小にします。 現在の仕様に、彼らが要求を否定するとき希望をいだいてクィックスタートOptionを削除するか、またはRate Request分野のゼロに合っているできるクィックStartルータはこの「自己を終えている」資産を提供します。 現在の仕様がQS TTLに無作為の初期の値を使用するので、できるクィックStartルータは、クィック-スタートRequestができる非迅速なスタートルータのために上流へ無効であるかどうかわかりません。 これは受信機がQS TTLの値に関して不正行為をするのを難しくするデザインを使用する費用です。
Appendix C. Quick-Start with DCCP
DCCPがある付録C.クィックスタート
DCCP is a new transport protocol for congestion-controlled, unreliable datagrams, intended for applications such as streaming media, Internet telephony, and online games. In DCCP, the application has a choice of congestion control mechanisms, with the currently-specified Congestion Control Identifiers (CCIDs) being CCID 2 for TCP-like congestion control, and CCID 3 for TCP Friendly Rate Control (TFRC), an equation-based form of congestion control. We refer the reader to [RFC4340] for a more detailed description of DCCP and congestion control mechanisms.
DCCPはストリーミング・メディアや、インターネット電話や、オンラインゲームなどのアプリケーションのために意図する混雑で制御されて、頼り無いデータグラムのための新しいトランスポート・プロトコルです。 DCCPでは、アプリケーションは混雑制御機構の選択を持っています、TCPのような輻輳制御のためのCCID2と、TCP Friendly Rate Control(TFRC)のためのCCID3である現在指定されたCongestion Control Identifiers(CCIDs)で、方程式ベースの形式の輻輳制御。 私たちはDCCPと混雑制御機構の、より詳細な記述について[RFC4340]の読者を参照します。
Because CCID 3 uses a rate-based congestion control mechanism, it raises some new issues about the use of Quick-Start with transport protocols. In this document, we don't attempt to specify the use of Quick-Start with DCCP. However, we do discuss some of the issues that might arise.
CCID3がレートベースの混雑制御機構を使用するので、それはトランスポート・プロトコルでクィック-始めの使用に関するいくつかの新規発行を提起します。 本書では、私たちは、DCCPとのクィック-始めの使用を指定するのを試みません。 しかしながら、私たちは起こるかもしれない問題のいくつかについて議論します。
In considering the use of Quick-Start with CCID 3 for requesting a higher initial sending rate, the following questions arise:
CCID3とのクィック-始めの、より高い初期の送付レートを要求する使用を考える際に、以下の質問は起こります:
Floyd, et al. Experimental [Page 70] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[70ページ]RFC4782クィックスタートとIP2007年1月
(1) How does the sender respond if a Quick-Start packet is dropped?
(1) クィック-スタートパケットが落とされるなら、送付者はどのように応じますか?
As in TCP, if an initial Quick-Start packet is dropped, the CCID
3 sender should revert to the congestion control mechanisms it
would have used if the Quick-Start Request had not been approved.
TCPのように、初期のクィック-スタートパケットが落とされて、クィック-スタートRequestが承認されていないなら、CCID3送付者はそれが使用した混雑制御機構に先祖帰りをするでしょうに。
(2) When does the sender decide there has been no feedback from the
receiver?
(2) 送付者は、受信機からのフィードバックが全くいつなかったと決めますか?
Unlike TCP, CCID 3 does not use acknowledgements for every
packet, or for every other packet. In contrast, the CCID 3
receiver sends feedback to the sender roughly once per round-trip
time. In CCID 3, the allowed sending rate is halved if no
feedback is received from the receiver in at least four round-
trip times (when the sender is sending at least one packet every
two round-trip times). When a Quick-Start Request is used, it
would seem necessary to use a smaller time interval, e.g., to
reduce the sending rate if no feedback arrives from the receiver
in at least two round-trip times.
TCPと異なって、CCID3はあらゆるパケット、または他のあらゆるパケットに承認を使用するというわけではありません。 対照的に、CCID3受信機は往復の時間に一度手荒くフィードバックを送付者に送ります。 CCID3では、受信機から丸い少なくとも4旅行時間でフィードバックを全く受け取らないなら(送付者が往復の2回あたり少なくとも1つのパケットに発信するとき)、許容送付レートを半分にします。 クィック-スタートRequestが使用されているとき、フィードバックが全く受信機から往復の少なくとも2回に到着しないなら、より小さい時間間隔を費やして、例えば送付レートを低下させるのは必要に思えるでしょう。
The question also arises of how the sending rate should be reduced after a period of no feedback from the receiver. As with TCP, the default CCID 3 response of halving the sending rate is not necessarily a sufficient response to the absence of feedback; an alternative is to reduce the sending rate to the sending rate that would have been used if no Quick-Start Request had been approved. That is, if a CCID 3 sender uses a Quick-Start Request, special rules might be required to handle the sender's response to a period of no feedback from the receiver regarding the Quick-Start packets.
また、質問は送付レートがフィードバックがない期間の後に受信機からどう低下するべきであるかを生じます。TCPのように、送付レートを半分にするデフォルトCCID3応答は必ずフィードバックの欠如への十分な応答であるというわけではありません。 代替手段はクィック-スタートRequestが全く承認されなかったなら使用された送付レートに送付レートを低下させることです。 すなわち、CCID3送付者がクィック-スタートRequestを使用するなら、特別な規則が、クィック-スタートパケットに関して受信機からフィードバックがない期間への送付者の応答を扱うのに必要であるかもしれません。
Similarly, in considering the use of Quick-Start with CCID 3 for requesting a higher sending rate after an idle period, the following questions arise:
同様に、CCID3とのクィック-始めの活動していない期間の後により高い送付レートを要求する使用を考える際に、以下の質問は起こります:
(1) What rate does the sender request?
(1) 送付者はどんなレートを要求しますか?
As in TCP, there is a straightforward answer to the rate request
that the CCID 3 sender should use in requesting a higher sending
rate after an idle period. The sender knows the current loss
event rate, either from its own calculations or from feedback
from the receiver, and can determine the sending rate allowed by
that loss event rate. This is the upper bound on the sending
rate that should be requested by the CCID 3 sender. A Quick-
Start Request is useful with CCID 3 when the sender is coming out
of an idle or underutilized period, because in standard
operation, CCID 3 does not allow the sender to send more than
twice as fast as the receiver has reported received in the most
recent feedback message.
TCPのように、CCID3送付者が活動していない期間の後により高い送付レートを要求する際に使用するべきであるレート要求の簡単な答えがあります。 送付者は、それ自身の計算かフィードバックから受信機から当期損失イベント率を知って、その損失イベント率によって許容された送付レートを測定できます。 これはCCID3送付者によって要求されているべきである送付レートの上限です。 CCID3によって、送付者が活動していないかunderutilizedされた期間から出て来る予定であるとき、クィックスタートRequestは役に立ちます、標準の操作では、CCID3が受信機が、最新のフィードバックメッセージで受け取られていると報告したより2倍速いほど送付者を発信させないので。
Floyd, et al. Experimental [Page 71] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[71ページ]RFC4782クィックスタートとIP2007年1月
(2) What is the response to loss?
(2) 損失への応答は何ですか?
The response to the loss of Quick-Start packets should be to
return to the sending rate that would have been used if Quick-
Start had not been requested.
クィック-スタートパケットの損失への応答はクィック始めが要求されなかったなら使用された送付レートに戻ることであるべきです。
(3) When does the sender decide there has been no feedback from the
receiver?
(3) 送付者は、受信機からのフィードバックが全くいつなかったと決めますか?
As in the case of the initial sending rate, it would seem prudent
to reduce the sending rate if no feedback is received from the
receiver in at least two round-trip times. It seems likely that,
in this case, the sending rate should be reduced to the sending
rate that would have been used if no Quick-Start Request had been
approved.
初期の送付レートに関するケースのように、受信機から往復の少なくとも2回でフィードバックを全く受け取らないなら、送付レートを低下させるのは慎重に思えるでしょう。 この場合、送付レートはクィック-スタートRequestが全く承認されなかったなら使用された送付レートに低下しそうであるべきです。
Appendix D. Possible Router Algorithm
付録のD.の可能なルータアルゴリズム
This specification does not tightly define the algorithm a router uses when deciding whether to approve a Quick-Start Rate Request or whether and how to reduce a Rate Request. A range of algorithms is likely useful in this space and we consider the algorithm a particular router uses to be a local policy decision. In addition, we believe that additional experimentation with router algorithms is necessary to have a solid understanding of the dynamics various algorithms impose. However, we provide one particular algorithm in this appendix as an example and as a framework for thinking about additional mechanisms.
この仕様はしっかり減少してクィック-スタートRate Requestを承認するかどうか、またはRate Requestを減少させる方法を決めるときルータが使用するアルゴリズムを定義しません。 さまざまなアルゴリズムがこのスペースでおそらく役に立ちます、そして、私たちは特定のルータが使用するアルゴリズムがローカルの政策決定であると考えます。 さらに、私たちは、ルータアルゴリズムがある追加実験が様々なアルゴリズムが課す力学の確実な理解を持つのに必要であると信じています。 しかしながら、私たちは例として枠組みとしてこの付録の1つの特定のアルゴリズムを追加メカニズムについて考えるのに提供します。
[SAF06] provides several algorithms routers can use to consider incoming Rate Requests. The decision process involves two algorithms. First, the router needs to track the link utilization over the recent past. Second, this utilization needs to be updated by the potential new bandwidth from recent Quick-Start approvals, and then compared with the router's notion of when it is underutilized enough to approve Quick-Start Requests (of some size).
[SAF06]はルータが入って来るRate Requestsを考えるのに使用できるいくつかのアルゴリズムを提供します。 決定の過程は2つのアルゴリズムにかかわります。最初に、ルータは、最近の過去の間のリンク利用を追跡する必要があります。 2番目に、この利用は、最近のクィック-スタート可決からの潜在的新しい帯域幅でアップデートして、次に、それがunderutilizedされる時に関するルータの概念がクィック-スタートRequests(何らかのサイズの)を承認できるくらい比較する必要があります。
First, we define the "peak utilization" estimation technique (from [SAF06]). This mechanism records the utilization of the link every S seconds and stores the most recent N of these measurements. The utilization is then taken as the highest utilization of the N samples. This method, therefore, keeps N*S seconds of history. This algorithm reacts rapidly to increases in the link utilization. In [SAF06], S is set to 0.15 seconds, and experiments use values for N ranging from 3 to 20.
まず最初に、私たちは「ピーク利用」見積りのテクニック([SAF06]からの)を定義します。 このメカニズムは、あらゆるSが後援するリンクの利用を記録して、これらのN最新の測定値を格納します。 そして、利用はNサンプルの最も高い利用としてみなされます。 したがって、この方法は、N*Sが秒の歴史であることを保ちます。 このアルゴリズムは急速にリンク利用の増加に反応します。 [SAF06]では、Sは0.15秒に設定されます、そして、実験はNの及ぶ3〜20までの値を使用します。
Second, we define the "target" algorithm for processing incoming Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
2番目に、私たちは処理の入って来るクィック-スタートRate Requests([SAF06]からも)のための「目標」アルゴリズムを定義します。 アルゴリズムは当てにします。
Floyd, et al. Experimental [Page 72] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[72ページ]RFC4782クィックスタートとIP2007年1月
on knowing the bandwidth of the outgoing link (which, in many cases, can be easily configured), the utilization of the outgoing link (from an estimation technique such as given above), and an estimate of the potential bandwidth from recent Quick-Start approvals.
最近のクィック-スタート可決から出発しているリンクの帯域幅(多くの場合、容易に、構成できる)、出発しているリンクの利用(上に与えるような見積りのテクニックからの)、および潜在的帯域幅の見積りを知ることに関して。
Tracking the potential bandwidth from recent Quick-Start approvals is another case where local policy dictates how it should be done. The simplest method, outlined in Section 8.2, is for the router to keep track of the aggregate Quick-Start rate requests approved in the most recent two or more time intervals, including the current time interval, and to use the sum of the aggregate rate requests over these time intervals as the estimate of the approved Rate Requests. The experiments in [SAF06] keep track of the aggregate approved Rate Requests over the most recent two time intervals, for intervals of 150 msec.
最近のクィック-スタート可決からの潜在的帯域幅を追跡するのは、ローカルの方針がそれがどのように完了しているべきであるかを決める別のケースです。 セクション8.2に概説されている中で最も簡単な方法は、現在の時間間隔を含んでいて、ルータが2回以上の最新の時間間隔で承認された集合クィック-スタートレート要求の動向をおさえて、これらの時間間隔の間、承認されたRate Requestsの見積りとして集合レート要求の合計を使用することです。 [SAF06]での実験は2回の最新の時間間隔の間、集合承認されたRate Requestsの動向をおさえます、150msecの間隔の間。
The target algorithm also depends on a threshold (qs_thresh) that is the fraction of the outgoing link bandwidth that represents the router's notion of "significantly underutilized". If the utilization, augmented by the potential bandwidth from recent Quick- Start approvals, is above this threshold, then no Quick-Start Rate Requests will be approved. If the utilization, again augmented by the potential bandwidth from recent Quick-Start approvals, is less than the threshold, then Rate Requests can be approved. The Rate Requests will be reduced such that the bandwidth allocated would not drive the utilization to more than the given threshold. The algorithm is:
また、目標アルゴリズムはルータの「かなりunderutilizedされていること」の概念を表す外向的なリンク帯域幅の部分である敷居(qs_脱穀)に依存します。 最近のクィックスタート可決からの潜在的帯域幅によって増大させられる利用がこの敷居を超えていると、クィック-スタートRate Requestsは全く承認されないでしょう。 再び最近のクィック-スタート可決からの潜在的帯域幅によって増大している利用が敷居以下であるなら、Rate Requestsを承認できます。 Rate Requestsは、割り当てられた帯域幅が与えられた敷居以上に利用を追い立てないように、減少するでしょう。 アルゴリズムは以下の通りです。
util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals;
if (util_bw < (qs_thresh * bandwidth))
{
approved = (qs_thresh * bandwidth) - util_bw;
if (rate_request < approved)
approved = rate_request;
approved = round_down (approved);
recent_qs_approvals += approved;
}
util_bwは帯域幅*利用と等しいです。 util_bw=util_bw+最近の_qs_可決。 (util_bw<(qs_脱穀*帯域幅))です。= 承認されて、承認されるなら(レート_要求<は承認しました)、(qs_脱穀*帯域幅)(util_bw)はレート_要求と等しいです; _下に(承認される)の周りの=を承認します; 最近の_qs_可決+=は承認しました;。
Also note that, given that Rate Requests are fairly coarse, the approved rate should be rounded down when it does not fall exactly on one of the rates allowed by the encoding scheme.
また、ちょうどコード化計画によって許容されたレートの1つに落ちないとき、Rate Requestsがかなり粗いなら承認されたレートが概数に切り下げられるべきであることに注意してください。
Routers that wish to keep close track of the allocated Quick-Start bandwidth could use Approved Rate reports to learn when rate requests had been decremented downstream in the network, and also to learn when a sender begins to use the approved Quick-Start Request.
割り当てられたクィック-スタート帯域幅の近い道を保ちたがっているルータは、レート要求がいつ川下でネットワークで減少したかを学んで、また、送付者がいつ承認されたクィック-スタートRequestを使用し始めるかを学ぶのにApproved Rateレポートを使用するかもしれません。
Floyd, et al. Experimental [Page 73] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[73ページ]RFC4782クィックスタートとIP2007年1月
Appendix E. Possible Additional Uses for the Quick-Start Option
クィックスタートオプションへの付録のE.の可能な追加用途
The Quick-Start Option contains a four-bit Function field in the third byte, enabling additional uses to be defined for the Quick- Start Option. In this section, we discuss some of the possible additional uses that have been discussed for Quick-Start. The Function field makes it easy to add new functions for the Quick- Start Option.
クィック-スタートOptionは3番目のバイトにおける4ビットのFunction分野を含んでいます、追加用途がクィックスタートOptionのために定義されるのを可能にして。 このセクションで、私たちはクィック-始めと議論した可能な追加用途のいくつかについて議論します。 Function分野で、クィックのための新しい機能がOptionを始動すると言い足すのが簡単になります。
Report of Current Sending Rate: A Quick-Start Request with the `Report of Current Sending Rate' codepoint set in the Function field would be using the Rate Request field to report the current estimated sending rate for that connection. This could accompany a second Quick-Start Request in the same packet containing a standard rate request, for a connection that is using Quick-Start to increase its current sending rate.
現在の送付レートのレポート: Function分野で用意ができている'Current Sending Rateのレポート'codepointとクィック-スタートRequestは、その接続の現在のおよそ送付速度を報告するのにRate Request分野を使用しているでしょう。 標準のレート要求を含んでいて、これは同じパケットで第2のクィック-スタートRequestに同伴するかもしれません、現在の送付レートを増加させるのにクィック-始めを使用している接続のために。
Request to Increase Sending Rate: A codepoint for `Request to Increase Sending Rate' in the Function field would indicate that the connection is not idle or just starting up, but is attempting to use Quick-Start to increase its current sending rate. This codepoint would not change the semantics of the Rate Request field.
発信を増加させるように、評価するよう要求してください: Function分野の'Increase Sending Rateへの要求'のためのcodepointは、接続が無駄でないかただ始動していますが、増加するのにクィック-始めを使用するのを試みるのが、現在の送付レートであることを示すでしょう。 このcodepointはRate Request分野の意味論を変えないでしょう。
RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for the RTT Estimate would contain one or more bits giving the sender's rough estimate of the round-trip time, if known. E.g., the sender could estimate whether the RTT was greater or less than 200 ms. Alternately, if the sender had an estimate of the RTT when it sends the Rate Request, the two-bit Reserved field at the end of the Quick-Start Option could be used for a coarse-grained encoding of the RTT.
RTTは見積もっています: 'RTT Estimate'のためのcodepointが使用されるなら、RTT Estimateのための分野は送付者の往復の現代の概算を与える1ビット以上を含んでいるでしょうに、知られているなら。 例えば、送付者は、RTTが、よりすばらしかったか、そして、200未満原稿がAlternatelyであると見積もることができました、Rate Requestを送るとき送付者にRTTの見積りがあったならRTTの下品なコード化にクィック-スタートOptionの端の安っぽいReserved分野は使用できました。
Informational Request: An Informational Request codepoint in the Function field would indicate that a request is purely informational, for the sender to find out if a rate request would be approved, and what size rate request would be approved when the Informational Request is sent. For example, an Informational Request could be followed one round-trip time later by a standard Quick-Start Request. A router approving an Informational Request would not consider this as an approval for Quick-Start bandwidth to be used, and would not be under any obligation to approve a similar standard Quick-Start Request one round-trip time later. An Informational Request with a rate request of zero could be used by the sender to find out if all of the routers along the path supported Quick-Start.
情報の要求: Function分野のInformational Request codepointは、送付者がレート要求を承認するだろうかどうかと、Informational Requestを送るときどんなサイズレート要求を承認するかを見つけるように要求が純粋に情報であることを示すでしょう。 例えば、Informational Requestは標準のクィック-スタートRequestによる後での続いている往復の1回であるかもしれません。 Informational Requestを承認するルータは、これがクィック-スタート帯域幅が使用されるための許可であるとみなさないで、また後での時の往復の同様の標準のクィック-スタートRequest1を承認するどんな義務の下にもないでしょう。 送付者は、経路に沿ったルータのすべてがクィック-開始を支持したかどうか見つけるのにゼロのレート要求があるInformational Requestを使用できました。
Use Format X for the Rate Request Field: A Quick-Start codepoint for `Use Format X for the Rate Request Field' would indicate that an alternate format was being used for the Rate Request field.
レート要求分野に形式Xを使用してください: クィック-始めは'使用のためにRate Request FieldのためのFormat Xをcodepointします。'交互の形式がRate Request分野に使用されていたのを示すでしょう。
Floyd, et al. Experimental [Page 74] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[74ページ]RFC4782クィックスタートとIP2007年1月
Do Not Decrement: A Do Not Decrement codepoint could be used for a Quick-Start Request where the sender would rather have the request denied than to have the rate request decremented in the network. This could be used if the sender was only interested in using Quick- Start if the original rate request was approved.
以下を減少させないでください。 送付者がレート要求をネットワークで減少させるより要求を否定させる方がましであるクィック-スタートRequestにDo Not Decrement codepointを使用できました。 オリジナルのレート要求が承認された場合にだけ送付者がクィック始めを使用したいと思うなら、これを使用できるでしょうに。
Temporary Bandwidth Use: A Temporary codepoint has been proposed to indicate that a connection would only use the requested bandwidth for a single time interval.
一時的な帯域幅使用: Temporary codepointは、接続が単一の時間間隔の間要求された帯域幅を使用するだけであるのを示すために提案されました。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(2001年9月)。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC3390] オールマンとM.とフロイド、S.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、2002年10月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, March 2004.
[RFC3742] フロイド、S.、「大きい混雑WindowsがあるTCPのための株式会社の遅れた出発」、RFC3742、2004年3月。
Informative References
有益な参照
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
Floyd, et al. Experimental [Page 75] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[75ページ]RFC4782クィックスタートとIP2007年1月
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997.
[RFC2140] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、1997年4月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased
Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] PoduriとK.とK.ニコルズ、「増加する初期のTCPウィンドウサイズのシミュレーション研究」、RFC2415、1998年9月。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC
2488, January 1999.
[RFC2488]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC
2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル'L2TP'にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March
2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L., and V. Paxson, "Stream Control Transmission Protocol",
RFC 2960, October 2000.
[RFC2960] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3124]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
Floyd, et al. Experimental [Page 76] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[76ページ]RFC4782クィックスタートとIP2007年1月
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002.
[RFC3360] フロイド、S.、「有害であると考えられた不適当なTCPリセット」、BCP60、RFC3360、2002年8月。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003.
[RFC3649]フロイド、2003年12月のS.、「大きい混雑WindowsのためのHighSpeed TCP」RFC3649。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", RFC
3662, December 2003.
[RFC3662]が祝福する、R.、ニコルズ、K.、およびK.ウェールレ、「微分されたサービスのための1ドメインあたり1つの下側の努力の振舞い(PDB)」、RFC3662(2003年12月)
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697] RajahalmeとJ.とコンタとA.と大工、B.とS.デアリング、「IPv6流れラベル仕様」、RFC3697、2004年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig,
R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
"Advice for Internet Subnetwork Designers", BCP 89, RFC
3819, July 2004.
[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC3948]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(2005年1月)。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[RFC4341] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、2006年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version
6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
with Larger Initial Windows. ACM Computer Communication
Review, July 1998.
[AHO98] M.オールマン、C.ヘイズ、およびS.オステルマン。 Larger Initial WindowsとのTCPの評価。 1998年7月のACMコンピュータコミュニケーションレビュー。
Floyd, et al. Experimental [Page 77] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[77ページ]RFC4782クィックスタートとIP2007年1月
[B05] Briscoe, B., "Review: Quick-Start for TCP and IP",
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>,
November 2005.
[B05] ブリスコウ、B.は「以下を見直します」。 「TCPとIPのためのクィックスタート」、<http://www.cs.ucl.ac.uk/スタッフ/B.ブリスコウ/pubs.html>、2005年11月。
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols
of the new GSM Phase 2+ General Packet Radio Service. IEEE
Communications Magazine, pages 94--104, August 1997.
[BW97] G.BrascheとB.Walke。 新しいGSM Phase2+汎用パケット無線システムの概念、Services、およびプロトコル。 IEEE Communications Magazine、94--104ページ、1997年8月。
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
Layer Protocol Tracing in a GPRS Network. In Proceedings of
the IEEE Vehicular Technology Conference (Fall VTC2002),
Vancouver, Canada, September 2002.
[GPAR02] A.Gurtov、M.Passoja、O.アールトー、およびM.Raitola。 GPRSネットワークにおけるマルチ層のプロトコルのたどること。 IEEE車両技術部会コンファレンス(秋のVTC2002)の議事、バンクーバー(カナダ)2002年9月に。
[H05] P. Hoffman, email, October 2005. Citation for
acknowledgement purposes only.
[H05]P.ホフマン、2005年10月に、メールしてください。 承認目的だけのための引用。
[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End
Protocol Semantics, Proc. USENIX Security Symposium 2001.
[HKP01] M.ハンドレー、C.Kreibich、およびV.パクソンは押しつけ検出をネットワークでつなぎます: Proc、回避、交通正常化、および終わらせる終わりは意味論について議定書の中で述べます。 USENIXセキュリティシンポジウム2001。
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
[Jac88] V.ジェーコブソンと輻輳回避とコントロール、ACM SIGCOMM。
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
Bandwidth: Measurement Methodology, Dynamics, and Relation
with TCP Throughput, SIGCOMM 2002.
[JD02] Manishジャイナ教徒、コンスタンチノスDovrolis、終わりから終わりへの利用可能な帯域幅: TCPスループット、SIGCOMM2002との測定方法論、力学、および関係。
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
Bandwidth Delay Connections", Proceedings, IEEE ICC '03,
May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
[K03]S.Kunniyur、「以下をマークするAntiECN」 「高帯域遅れコネクションズのマーク計画」(議事、IEEE ICC'03)は2003が'そうするかもしれません。 <http://www.seas.upenn.edu/~kunniyur/>。
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
Sterbenz. Explicit Transport Error Notification (ETEN) for
Error-Prone Wireless and Satellite Networks. Technical
Report No. 8333, BBN Technologies, March 2002.
<http://www.icir.org/mallman/papers/>.
[KAPS02]ラジェッシュ・クリシュナン、オールマン、クレイグPartridge、ジェームスP.G.Sterbenzをマークしてください。 誤り傾向がある無線電信と衛星ネットワークのための明白な輸送エラー通知(ETEN)。 技術報告書No.8333、BBN技術、2002年3月。 <http://www.icir.org/mallman/papers/>。
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002.
<http://ana.lcs.mit.edu/dina/XCP/>.
[KHR02] ダイナKatabi、マークハンドレー、およびチャールズ・レールス、インターネット混雑は将来の高帯域遅れ製品環境のために制御されます。 2002年8月のACM Sigcomm2002。 <http://ana.lcs.mit.edu/dina/XCP/>。
[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer. INFOCOM 2003,
April 2003.
[KK03]A.KuzmanovicとE.W.ナイトです。 TCP-LP: 低い優先権データ転送のための分配されたアルゴリズム。 2003年4月のINFOCOM2003。
Floyd, et al. Experimental [Page 78] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[78ページ]RFC4782クィックスタートとIP2007年1月
[KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig
Partridge, Mark Allman. Explicit Transport Error
Notification (ETEN) for Error-Prone Wireless and Satellite
Networks. Computer Networks, 46(3), October 2004.
[KSEPA04]ラジェッシュ・クリシュナン、ジェームスSterbenz(ウエスリーEddy、クレイグPartridge)はオールマンをマークします。 誤り傾向がある無線電信と衛星ネットワークのための明白な輸送エラー通知(ETEN)。 コンピュータネットワーク、46(3)、2004年10月。
[L05] Guohan Lu, Nonce in TCP Quick Start, September 2005.
<http://www.net-glyph.org/~lgh/nonce-usage.pdf>.
[L05]Guohan Lu、TCPの迅速な始め、2005年9月の一回だけ。 <~lgh/一回だけhttp://www.net-glyph.org/usage.pdf>。
[MH06] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", Work in Progress, December 2006.
[MH06] 「Packetization層の経路MTU発見」というマシス、M.、およびJ.ヘフナーは進歩、2006年12月に働いています。
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring
Interactions Between Transport Protocols and Middleboxes,
Internet Measurement Conference 2004, August 2004.
<http://www.icir.org/tbit/".
[MAF04] アルベルト・メディナ、オールマンをマークしてください、そして、フロイドを出撃させてください、トランスポート・プロトコルとMiddleboxesとの相互作用を測定して、インターネット測定コンファレンス2004、2004年8月。 「<http://www.icir.org/tbit/。」
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring
the Evolution of Transport Protocols in the Internet.
Computer Communications Review, April 2005.
[MAF05]アルベルト・メディナ、オールマンをマークしてください、そして、フロイドを出撃させてください。 インターネットでのトランスポート・プロトコルの発展を測定します。 コンピュータコミュニケーションは2005年4月に再検討されます。
[MaxNet] MaxNet Home Page,
<http://netlab.caltech.edu/~bartek/maxnet.htm>.
[MaxNet]MaxNetホームページ、<http://netlab.caltech.edu/~bartek/maxnet.htm>。
[P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection,
report to John Heidemann, 2000, private communication.
Citation for acknowledgement purposes only.
[P00]は、Park(TCP ConnectionのBandwidthディスカバリー)がジョンHeidemann、2000、私信に報告するとJoon歌いました。 承認目的だけのための引用。
[PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern
Paxson, Brian Tierney. A First Look at Modern Enterprise
Traffic. ACM SIGCOMM/USENIX Internet Measurement
Conference, October 2005.
[PABL+05] Ruoming心痛、マークオールマン、マイク・ベネット、ジェイソン・リー、バーン・パクソン、ブライアン・ティアニー。 現代企業交通への最初の一見。 2005年10月のACM SIGCOMM/USENIXインターネット測定コンファレンス。
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
Krishnan, James P.G. Sterbenz. A Swifter Start for TCP.
Technical Report No. 8339, BBN Technologies, March 2002.
<http://www.icir.org/mallman/papers/>.
[PRAKS02] クレイグPartridge、デニスロックウェルはオールマン、ラジェッシュ・クリシュナン、ジェームスP.G.Sterbenzをマークします。 TCPには、より迅速な始め。 技術報告書No.8339、BBN技術、2002年3月。 <http://www.icir.org/mallman/papers/>。
[RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing, Preprint-Reihe des Fachbereichs Mathematik -
Informatik, No. 15, Institute of Computer Science,
University of Innsbruck, Austria, October 2003.
[RW03] IP Option Processing、Preprint-Reihe des Fachbereichs MathematikのMattiaロッシィとマイケルWelzl、On Impact--Informatik、No.15、コンピュータ科学協会(インスブルック(オーストリア)2003年10月の大学)。
[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing - Part 2, Preprint-Reihe des Fachbereichs
Mathematik - Informatik, No. 26, Institute of Computer
Science, University of Innsbruck, Austria, July 2004.
[RW04] IP Option Processing--第2部、Preprint-Reihe des Fachbereichs Mathematik--Informatik、No.26、コンピュータ科学協会(インスブルック(オーストリア)2004年7月の大学)のMattiaロッシィとマイケルWelzl、On Impact。
Floyd, et al. Experimental [Page 79] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[79ページ]RFC4782クィックスタートとIP2007年1月
[S02] Ion Stoica, private communication, 2002. Citation for
acknowledgement purposes only.
[S02] Ionストイカ、私信、2002。 承認目的だけのための引用。
[SAF06] Pasi Sarolahti, Mark Allman, and Sally Floyd. Determining
an Appropriate Sending Rate Over an Underutilized Network
Path. February 2006.
<http://www.icir.org/floyd/quickstart.html>.
[SAF06]パシSarolahti、オールマンをマークしてください、そして、フロイドを出撃させてください。 Underutilizedネットワーク経路の上で適切な送付レートを測定します。 2006年2月。 <http://www.icir.org/floyd/quickstart.html>。
[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare
network bandwidth to improve TCP performance", ACM SIGCOMM
2005 Work in Progress session, August 2005,
<https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf>.
[SGF05] シン、M.、グーハ、S.、およびP.フランシス、「予備を利用して、帯域幅をネットワークでつないで、TCP性能を向上させてください」、ProgressセッションにおけるACM SIGCOMM2005Work、2005年8月、<https://www.guha.cc/saikat/パブ/sigcomm05-lowtcp.pdf>。
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce,
Washington, D.C., publication 180-1, April 1995.
[SHA1]「安全な細切れ肉料理規格」、FIPS、米国商務省、ワシントンDC公表180-1、1995年4月。
[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP
Quick Start with NS-2. Class Project, December 2002. Not
publicly available; citation for acknowledgement purposes
only.
[SH02]Srikanth SundarrajanとジョンHeidemann。 ナノ秒-2があるTCPの迅速な始めの研究。 クラスは2002年12月に突出します。 公的に利用可能でない。 承認目的だけのための引用。
[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A
Mechanism for Background Transfers. OSDI 2002.
[V02] A.Venkataramani、R.Kokku、およびM.Dahlin。 TCPニース: バックグラウンドのためのメカニズムは移されます。 OSDI2002。
[VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of
Idle TCP Connections, Technical Report 97-661, University
of Southern California, November 1997.
活動していないTCPコネクションズの再開を改良して、VisweswaraiahとJ.Heidemannに対して技術的な[VH97]は97-661に報告します、南カリフォルニアの大学、1997年11月。
[W00] Michael Welzl: PTP: Better Feedback for Adaptive
Distributed Multimedia Applications on the Internet, IPCCC
2000 (19th IEEE International Performance, Computing, And
Communications Conference), Phoenix, Arizona, USA, 20-22
February 2000.
<http://www.welzl.at/research/publications/>.
[W00]マイケルWelzl: PTP: インターネット(IPCCC2000(第19IEEEの国際パフォーマンス、コンピューティング、およびコミュニケーションコンファレンス)、フェニックス(アリゾナ)(米国)2000年2月20-22日)における適応型の分散型マルチメディアアプリケーションのための、より良いフィードバック。 <http://www.welzl.at/research/publications/>。
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the
Constancy of Internet Path Properties, Proc. ACM SIGCOMM
Internet Measurement Workshop, November 2001.
[ZDPS01]Y.チャン、N.ダッフィールド、対パクソン、およびインターネット経路の特性、Procの不変性のS.Shenker。 2001年11月のACM SIGCOMMインターネット測定ワークショップ。
[ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data
Transfers: Theory, Architectural Support, and Simulation
Results, NOSSDAV 2000, June 2000.
[ZQK00] 短いデータ転送を早くするY.チャン、L.Qiu、およびS.Keshav: NOSSDAV2000、理論、建築サポート、およびシミュレーションは結果として生じて、6月は2000です。
Floyd, et al. Experimental [Page 80] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[80ページ]RFC4782クィックスタートとIP2007年1月
Authors' Addresses
作者のアドレス
Sally Floyd Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) EMail: floyd@icir.org URL: http://www.icir.org/floyd/
フロイドPhoneを出撃させてください: +1 (510) 666-2989 ICIR(インターネット調査のためのICSIセンター)はメールします: floyd@icir.org URL: http://www.icir.org/floyd/
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/
マークオールマンICSIは1947Center通り、Suite600バークレー、カリフォルニア94704-1198が電話をする研究をインターネットの中心に置きます: (440) 235-1792 メールしてください: mallman@icir.org URL: http://www.icir.org/mallman/
Amit Jain F5 Networks EMail: a.jain@f5.com
Amitのジャイナ教のF5ネットワークはメールされます: a.jain@f5.com
Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 EMail: pasi.sarolahti@iki.fi
パシSarolahtiノキアリサーチセンター私書箱407FI-00045Nokia Groupフィンランド電話: +358 50 4876607はメールされます: pasi.sarolahti@iki.fi
Floyd, et al. Experimental [Page 81] RFC 4782 Quick-Start for TCP and IP January 2007
フロイド、他 TCPのための実験的な[81ページ]RFC4782クィックスタートとIP2007年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Floyd, et al. Experimental [Page 82]
フロイド、他 実験的[82ページ]
一覧
スポンサーリンク
