RFC4336 日本語訳
4336 Problem Statement for the Datagram Congestion Control Protocol(DCCP). S. Floyd, M. Handley, E. Kohler. March 2006. (Format: TXT=53585 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Floyd
Request for Comments: 4336 ICIR
Category: Informational M. Handley
UCL
E. Kohler
UCLA
March 2006
Network Working Group S. Floyd Request for Comments: 4336 ICIR Category: Informational M. Handley UCL E. Kohler UCLA March 2006
Problem Statement for the
Datagram Congestion Control Protocol (DCCP)
Problem Statement for the Datagram Congestion Control Protocol (DCCP)
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
Abstract
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.
Floyd, et al. Informational [Page 1] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 1] RFC 4336 Problem Statement for DCCP March 2006
Table of Contents
Table of Contents
1. Introduction ....................................................2
2. Problem Space ...................................................3
2.1. Congestion Control for Unreliable Transfer .................4
2.2. Overhead ...................................................6
2.3. Firewall Traversal .........................................6
2.4. Parameter Negotiation ......................................7
3. Solution Space for Congestion Control of Unreliable Flows .......7
3.1. Providing Congestion Control Above UDP .....................8
3.1.1. The Burden on the Application Designer ..............8
3.1.2. Difficulties with ECN ...............................8
3.1.3. The Evasion of Congestion Control ..................10
3.2. Providing Congestion Control Below UDP ....................10
3.2.1. Case 1: Congestion Feedback at the Application .....11
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11
3.3. Providing Congestion Control at the Transport Layer .......12
3.3.1. Modifying TCP? .....................................12
3.3.2. Unreliable Variants of SCTP? .......................13
3.3.3. Modifying RTP? .....................................14
3.3.4. Designing a New Transport Protocol .................14
4. Selling Congestion Control to Reluctant Applications ...........15
5. Additional Design Considerations ...............................15
6. Transport Requirements of Request/Response Applications ........16
7. Summary of Recommendations .....................................17
8. Security Considerations ........................................18
9. Acknowledgements ...............................................18
Informative References ............................................19
1. Introduction ....................................................2 2. Problem Space ...................................................3 2.1. Congestion Control for Unreliable Transfer .................4 2.2. Overhead ...................................................6 2.3. Firewall Traversal .........................................6 2.4. Parameter Negotiation ......................................7 3. Solution Space for Congestion Control of Unreliable Flows .......7 3.1. Providing Congestion Control Above UDP .....................8 3.1.1. The Burden on the Application Designer ..............8 3.1.2. Difficulties with ECN ...............................8 3.1.3. The Evasion of Congestion Control ..................10 3.2. Providing Congestion Control Below UDP ....................10 3.2.1. Case 1: Congestion Feedback at the Application .....11 3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11 3.3. Providing Congestion Control at the Transport Layer .......12 3.3.1. Modifying TCP? .....................................12 3.3.2. Unreliable Variants of SCTP? .......................13 3.3.3. Modifying RTP? .....................................14 3.3.4. Designing a New Transport Protocol .................14 4. Selling Congestion Control to Reluctant Applications ...........15 5. Additional Design Considerations ...............................15 6. Transport Requirements of Request/Response Applications ........16 7. Summary of Recommendations .....................................17 8. Security Considerations ........................................18 9. Acknowledgements ...............................................18 Informative References ............................................19
1. Introduction
1. Introduction
Historically, the great majority of Internet unicast traffic has used congestion-controlled TCP, with UDP making up most of the remainder. UDP has mainly been used for short, request-response transfers, like DNS and SNMP, that wish to avoid TCP's three-way handshake, retransmission, and/or stateful connections. UDP also avoids TCP's built-in end-to-end congestion control, and UDP applications tended not to implement their own congestion control. However, since UDP traffic volume was small relative to congestion-controlled TCP flows, the network didn't collapse.
Historically, the great majority of Internet unicast traffic has used congestion-controlled TCP, with UDP making up most of the remainder. UDP has mainly been used for short, request-response transfers, like DNS and SNMP, that wish to avoid TCP's three-way handshake, retransmission, and/or stateful connections. UDP also avoids TCP's built-in end-to-end congestion control, and UDP applications tended not to implement their own congestion control. However, since UDP traffic volume was small relative to congestion-controlled TCP flows, the network didn't collapse.
Recent years have seen the growth of applications that use UDP in a different way. These applications, including streaming audio, Internet telephony, and multiplayer and massively multiplayer on-line games, share a preference for timeliness over reliability. TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements; thus, the applications use UDP instead. This growth of long-lived non-congestion-controlled traffic, relative to
Recent years have seen the growth of applications that use UDP in a different way. These applications, including streaming audio, Internet telephony, and multiplayer and massively multiplayer on-line games, share a preference for timeliness over reliability. TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements; thus, the applications use UDP instead. This growth of long-lived non-congestion-controlled traffic, relative to
Floyd, et al. Informational [Page 2] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 2] RFC 4336 Problem Statement for DCCP March 2006
congestion-controlled traffic, poses a real threat to the overall health of the Internet [RFC2914, RFC3714].
congestion-controlled traffic, poses a real threat to the overall health of the Internet [RFC2914, RFC3714].
Applications could implement their own congestion control mechanisms on a case-by-case basis, with encouragement from the IETF. Some already do this. However, experience shows that congestion control is difficult to get right, and many application writers would like to avoid reinventing this particular wheel. We believe that a new protocol is needed, one that combines unreliable datagram delivery with built-in congestion control. This protocol will act as an enabling technology: existing and new applications could easily use it to transfer timely data without destabilizing the Internet.
Applications could implement their own congestion control mechanisms on a case-by-case basis, with encouragement from the IETF. Some already do this. However, experience shows that congestion control is difficult to get right, and many application writers would like to avoid reinventing this particular wheel. We believe that a new protocol is needed, one that combines unreliable datagram delivery with built-in congestion control. This protocol will act as an enabling technology: existing and new applications could easily use it to transfer timely data without destabilizing the Internet.
This document provides a problem statement for such a protocol. We list the properties the protocol should have, then explain why those properties are necessary. We describe why a new protocol is the best solution for the more general problem of bringing congestion control to unreliable flows of unicast datagrams, and discuss briefly subsidiary requirements for mobility, defense against Denial of Service (DoS) attacks and spoofing, interoperation with RTP, and interactions with Network Address Translators (NATs) and firewalls.
This document provides a problem statement for such a protocol. We list the properties the protocol should have, then explain why those properties are necessary. We describe why a new protocol is the best solution for the more general problem of bringing congestion control to unreliable flows of unicast datagrams, and discuss briefly subsidiary requirements for mobility, defense against Denial of Service (DoS) attacks and spoofing, interoperation with RTP, and interactions with Network Address Translators (NATs) and firewalls.
One of the design preferences that we bring to this question is a preference for a clean, understandable, low-overhead, and minimal protocol. As described later in this document, this results in the design decision to leave functionality such as reliability or Forward Error Correction (FEC) to be layered on top, rather than provided in the transport protocol itself.
One of the design preferences that we bring to this question is a preference for a clean, understandable, low-overhead, and minimal protocol. As described later in this document, this results in the design decision to leave functionality such as reliability or Forward Error Correction (FEC) to be layered on top, rather than provided in the transport protocol itself.
This document began in 2002 as a formalization of the goals of DCCP, the Datagram Congestion Control Protocol [RFC4340]. We intended DCCP to satisfy this problem statement, and thus the original reasoning behind many of DCCP's design choices can be found here. However, we believed, and continue to believe, that the problem should be solved whether or not DCCP is the chosen solution.
This document began in 2002 as a formalization of the goals of DCCP, the Datagram Congestion Control Protocol [RFC4340]. We intended DCCP to satisfy this problem statement, and thus the original reasoning behind many of DCCP's design choices can be found here. However, we believed, and continue to believe, that the problem should be solved whether or not DCCP is the chosen solution.
2. Problem Space
2. Problem Space
We perceive a number of problems related to the use of unreliable data flows in the Internet. The major issues are the following:
We perceive a number of problems related to the use of unreliable data flows in the Internet. The major issues are the following:
o The potential for non-congestion-controlled datagram flows to
cause congestion collapse of the network. (See Section 5 of
[RFC2914] and Section 2 of [RFC3714].)
o The potential for non-congestion-controlled datagram flows to cause congestion collapse of the network. (See Section 5 of [RFC2914] and Section 2 of [RFC3714].)
Floyd, et al. Informational [Page 3] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 3] RFC 4336 Problem Statement for DCCP March 2006
o The difficulty of correctly implementing effective congestion
control mechanisms for unreliable datagram flows.
o The difficulty of correctly implementing effective congestion control mechanisms for unreliable datagram flows.
o The lack of a standard solution for reliably transmitting
congestion feedback for an unreliable data flow.
o The lack of a standard solution for reliably transmitting congestion feedback for an unreliable data flow.
o The lack of a standard solution for negotiating Explicit
Congestion Notification (ECN) [RFC3168] usage for unreliable
flows.
o The lack of a standard solution for negotiating Explicit Congestion Notification (ECN) [RFC3168] usage for unreliable flows.
o The lack of a choice of TCP-friendly congestion control
mechanisms.
o The lack of a choice of TCP-friendly congestion control mechanisms.
We assume that most application writers would use congestion control for long-lived unreliable flows if it were available in a standard, easy-to-use form.
We assume that most application writers would use congestion control for long-lived unreliable flows if it were available in a standard, easy-to-use form.
More minor issues include the following:
More minor issues include the following:
o The difficulty of deploying applications using UDP-based flows in
the presence of firewalls.
o The difficulty of deploying applications using UDP-based flows in the presence of firewalls.
o The desire to have a single way to negotiate congestion control
parameters for unreliable flows, independently of the signalling
protocol used to set up the flow.
o The desire to have a single way to negotiate congestion control parameters for unreliable flows, independently of the signalling protocol used to set up the flow.
o The desire for low per-packet byte overhead.
o The desire for low per-packet byte overhead.
The subsections below discuss these problems of providing congestion control, traversing firewalls, and negotiating parameters in more detail. A separate subsection also discusses the problem of minimizing the overhead of packet headers.
The subsections below discuss these problems of providing congestion control, traversing firewalls, and negotiating parameters in more detail. A separate subsection also discusses the problem of minimizing the overhead of packet headers.
2.1. Congestion Control for Unreliable Transfer
2.1. Congestion Control for Unreliable Transfer
We aim to bring easy-to-use congestion control mechanisms to applications that generate large or long-lived flows of unreliable datagrams, such as RealAudio, Internet telephony, and multiplayer games. Our motivation is to avoid congestion collapse. (The short flows generated by request-response applications, such as DNS and SNMP, don't cause congestion in practice, and any congestion control mechanism would take effect between flows, not within a single end- to-end transfer of information.) However, before designing a congestion control mechanism for these applications, we must understand why they use unreliable datagrams in the first place, lest we destroy the very properties they require.
We aim to bring easy-to-use congestion control mechanisms to applications that generate large or long-lived flows of unreliable datagrams, such as RealAudio, Internet telephony, and multiplayer games. Our motivation is to avoid congestion collapse. (The short flows generated by request-response applications, such as DNS and SNMP, don't cause congestion in practice, and any congestion control mechanism would take effect between flows, not within a single end- to-end transfer of information.) However, before designing a congestion control mechanism for these applications, we must understand why they use unreliable datagrams in the first place, lest we destroy the very properties they require.
Floyd, et al. Informational [Page 4] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 4] RFC 4336 Problem Statement for DCCP March 2006
There are several reasons why protocols currently use UDP instead of TCP, among them:
There are several reasons why protocols currently use UDP instead of TCP, among them:
o Startup Delay: they wish to avoid the delay of a three-way
handshake before initiating data transfer.
o Startup Delay: they wish to avoid the delay of a three-way handshake before initiating data transfer.
o Statelessness: they wish to avoid holding connection state, and
the potential state-holding attacks that come with this.
o Statelessness: they wish to avoid holding connection state, and the potential state-holding attacks that come with this.
o Trading of Reliability against Timing: the data being sent is
timely in the sense that if it is not delivered by some deadline
(typically a small number of RTTs), then the data will not be
useful at the receiver.
o Trading of Reliability against Timing: the data being sent is timely in the sense that if it is not delivered by some deadline (typically a small number of RTTs), then the data will not be useful at the receiver.
Of these issues, applications that generate large or long-lived flows of datagrams, such as media transfer and games, mostly care about controlling the trade-off between timing and reliability. Such applications use UDP because when they send a datagram, they wish to send the most appropriate data in that datagram. If the datagram is lost, they may or may not resend the same data, depending on whether the data will still be useful at the receiver. Data may no longer be useful for many reasons:
Of these issues, applications that generate large or long-lived flows of datagrams, such as media transfer and games, mostly care about controlling the trade-off between timing and reliability. Such applications use UDP because when they send a datagram, they wish to send the most appropriate data in that datagram. If the datagram is lost, they may or may not resend the same data, depending on whether the data will still be useful at the receiver. Data may no longer be useful for many reasons:
o In a telephony or streaming video session, data in a packet
comprises a timeslice of a continuous stream. Once a timeslice
has been played out, the next timeslice is required immediately.
If the data comprising that timeslice arrives at some later time,
then it is no longer useful. Such applications can cope with
masking the effects of missing packets to some extent, so when the
sender transmits its next packet, it is important for it to only
send data that has a good chance of arriving in time for its
playout.
o In a telephony or streaming video session, data in a packet comprises a timeslice of a continuous stream. Once a timeslice has been played out, the next timeslice is required immediately. If the data comprising that timeslice arrives at some later time, then it is no longer useful. Such applications can cope with masking the effects of missing packets to some extent, so when the sender transmits its next packet, it is important for it to only send data that has a good chance of arriving in time for its playout.
o In an interactive game or virtual-reality session, position
information is transient. If a datagram containing position
information is lost, resending the old position does not usually
make sense -- rather, every position information datagram should
contain the latest position information.
o In an interactive game or virtual-reality session, position information is transient. If a datagram containing position information is lost, resending the old position does not usually make sense -- rather, every position information datagram should contain the latest position information.
In a congestion-controlled flow, the allowed packet sending rate depends on measured network congestion. Thus, some control is given up to the congestion control mechanism, which determines precisely when packets can be sent. However, applications could still decide, at transmission time, which information to put in a packet. TCP doesn't allow control over this; these applications demand it.
In a congestion-controlled flow, the allowed packet sending rate depends on measured network congestion. Thus, some control is given up to the congestion control mechanism, which determines precisely when packets can be sent. However, applications could still decide, at transmission time, which information to put in a packet. TCP doesn't allow control over this; these applications demand it.
Often, these applications (especially games and telephony applications) work on very short playout timescales. Whilst they are
Often, these applications (especially games and telephony applications) work on very short playout timescales. Whilst they are
Floyd, et al. Informational [Page 5] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 5] RFC 4336 Problem Statement for DCCP March 2006
usually able to adjust their transmission rate based on congestion feedback, they do have constraints on how this adaptation can be performed so that it has minimal impact on the quality of the session. Thus, they tend to need some control over the short-term dynamics of the congestion control algorithm, whilst being fair to other traffic on medium timescales. This control includes, but is not limited to, some influence on which congestion control algorithm should be used -- for example, TCP-Friendly Rate Control (TFRC) [RFC3448] rather than strict TCP-like congestion control. (TFRC has been standardized in the IETF as a congestion control mechanism that adjusts its sending rate more smoothly than TCP does, while maintaining long-term fair bandwidth sharing with TCP [RFC3448].)
usually able to adjust their transmission rate based on congestion feedback, they do have constraints on how this adaptation can be performed so that it has minimal impact on the quality of the session. Thus, they tend to need some control over the short-term dynamics of the congestion control algorithm, whilst being fair to other traffic on medium timescales. This control includes, but is not limited to, some influence on which congestion control algorithm should be used -- for example, TCP-Friendly Rate Control (TFRC) [RFC3448] rather than strict TCP-like congestion control. (TFRC has been standardized in the IETF as a congestion control mechanism that adjusts its sending rate more smoothly than TCP does, while maintaining long-term fair bandwidth sharing with TCP [RFC3448].)
2.2. Overhead
2.2. Overhead
The applications we are concerned with often send compressed data, or send frequent small packets. For example, when Internet telephony or streaming media are used over low-bandwidth modem links, highly compressing the payload data is essential. For Internet telephony applications and for games, the requirement is for low delay, and hence small packets are sent frequently.
The applications we are concerned with often send compressed data, or send frequent small packets. For example, when Internet telephony or streaming media are used over low-bandwidth modem links, highly compressing the payload data is essential. For Internet telephony applications and for games, the requirement is for low delay, and hence small packets are sent frequently.
For example, a telephony application sending a 5.6 Kbps data stream but wanting moderately low delay may send a packet every 20 ms, sending only 14 data bytes in each packet. In addition, 20 bytes is taken up by the IP header, with additional bytes for transport and/or application headers. Clearly, it is desirable for such an application to have a low-overhead transport protocol header.
For example, a telephony application sending a 5.6 Kbps data stream but wanting moderately low delay may send a packet every 20 ms, sending only 14 data bytes in each packet. In addition, 20 bytes is taken up by the IP header, with additional bytes for transport and/or application headers. Clearly, it is desirable for such an application to have a low-overhead transport protocol header.
In some cases, the correct solution would be to use link-based packet header compression to compress the packet headers, although we cannot guarantee the availability of such compression schemes on any particular link.
In some cases, the correct solution would be to use link-based packet header compression to compress the packet headers, although we cannot guarantee the availability of such compression schemes on any particular link.
The delay of data until after the completion of a handshake also represents potentially unnecessary overhead. A new protocol might therefore allow senders to include some data on their initial datagrams.
The delay of data until after the completion of a handshake also represents potentially unnecessary overhead. A new protocol might therefore allow senders to include some data on their initial datagrams.
2.3. Firewall Traversal
2.3. Firewall Traversal
Applications requiring a flow of unreliable datagrams currently tend to use signalling protocols such as the Real Time Streaming Protocol (RTSP) [RFC2326], SIP [RFC3261], and H.323 in conjunction with UDP for the data flow. The initial setup request uses a signalling protocol to locate the correct remote end-system for the data flow, sometimes after being redirected or relayed to other machines.
Applications requiring a flow of unreliable datagrams currently tend to use signalling protocols such as the Real Time Streaming Protocol (RTSP) [RFC2326], SIP [RFC3261], and H.323 in conjunction with UDP for the data flow. The initial setup request uses a signalling protocol to locate the correct remote end-system for the data flow, sometimes after being redirected or relayed to other machines.
Floyd, et al. Informational [Page 6] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 6] RFC 4336 Problem Statement for DCCP March 2006
As UDP flows contain no explicit setup and teardown, it is hard for firewalls to handle them correctly. Typically, the firewall needs to parse RTSP, SIP, and H.323 to obtain the information necessary to open a hole in the firewall. Although, for bi-directional flows, the firewall can open a bi-directional hole if it receives a UDP packet from inside the firewall, in this case the firewall can't easily know when to close the hole again.
As UDP flows contain no explicit setup and teardown, it is hard for firewalls to handle them correctly. Typically, the firewall needs to parse RTSP, SIP, and H.323 to obtain the information necessary to open a hole in the firewall. Although, for bi-directional flows, the firewall can open a bi-directional hole if it receives a UDP packet from inside the firewall, in this case the firewall can't easily know when to close the hole again.
While we do not consider these to be major problems, they are nonetheless issues that application designers face. Currently, streaming media players attempt UDP first, and then switch to TCP if UDP is not successful. Streaming media over TCP is undesirable and can result in the receiver needing to temporarily halt playout while it "rebuffers" data. Telephony applications don't even have this option.
While we do not consider these to be major problems, they are nonetheless issues that application designers face. Currently, streaming media players attempt UDP first, and then switch to TCP if UDP is not successful. Streaming media over TCP is undesirable and can result in the receiver needing to temporarily halt playout while it "rebuffers" data. Telephony applications don't even have this option.
2.4. Parameter Negotiation
2.4. Parameter Negotiation
Different applications have different requirements for congestion control, which may map into different congestion feedback. Examples include ECN capability and desired congestion control dynamics (the choice of congestion control algorithm and, therefore, the form of feedback information required). Such parameters need to be reliably negotiated before congestion control can function correctly.
Different applications have different requirements for congestion control, which may map into different congestion feedback. Examples include ECN capability and desired congestion control dynamics (the choice of congestion control algorithm and, therefore, the form of feedback information required). Such parameters need to be reliably negotiated before congestion control can function correctly.
While this negotiation could be performed using signalling protocols such as SIP, RTSP, and H.323, it would be desirable to have a single standard way of negotiating these transport parameters. This is of particular importance with ECN, where sending ECN-marked packets to a non-ECN-capable receiver can cause significant congestion problems to other flows. We discuss the ECN issue in more detail below.
While this negotiation could be performed using signalling protocols such as SIP, RTSP, and H.323, it would be desirable to have a single standard way of negotiating these transport parameters. This is of particular importance with ECN, where sending ECN-marked packets to a non-ECN-capable receiver can cause significant congestion problems to other flows. We discuss the ECN issue in more detail below.
3. Solution Space for Congestion Control of Unreliable Flows
3. Solution Space for Congestion Control of Unreliable Flows
We thus want to provide congestion control for unreliable flows, providing both ECN and the choice of different forms of congestion control, and providing moderate overhead in terms of packet size, state, and CPU processing. There are a number of options for providing end-to-end congestion control for the unicast traffic that currently uses UDP, in terms of the layer that provides the congestion control mechanism:
We thus want to provide congestion control for unreliable flows, providing both ECN and the choice of different forms of congestion control, and providing moderate overhead in terms of packet size, state, and CPU processing. There are a number of options for providing end-to-end congestion control for the unicast traffic that currently uses UDP, in terms of the layer that provides the congestion control mechanism:
o Congestion control above UDP.
o Congestion control above UDP.
o Congestion control below UDP.
o Congestion control below UDP.
o Congestion control at the transport layer in an alternative to
UDP.
o Congestion control at the transport layer in an alternative to UDP.
Floyd, et al. Informational [Page 7] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 7] RFC 4336 Problem Statement for DCCP March 2006
We explore these alternatives in the sections below. The concerns from the discussions below have convinced us that the best way to provide congestion control for unreliable flows is to provide congestion control at the transport layer, as an alternative to the use of UDP and TCP.
We explore these alternatives in the sections below. The concerns from the discussions below have convinced us that the best way to provide congestion control for unreliable flows is to provide congestion control at the transport layer, as an alternative to the use of UDP and TCP.
3.1. Providing Congestion Control Above UDP
3.1. Providing Congestion Control Above UDP
One possibility would be to provide congestion control at the application layer, or at some other layer above UDP. This would allow the congestion control mechanism to be closely integrated with the application itself.
One possibility would be to provide congestion control at the application layer, or at some other layer above UDP. This would allow the congestion control mechanism to be closely integrated with the application itself.
3.1.1. The Burden on the Application Designer
3.1.1. The Burden on the Application Designer
A key disadvantage of providing congestion control above UDP is that it places an unnecessary burden on the application-level designer, who might be just as happy to use the congestion control provided by a lower layer. If the application can rely on a lower layer that gives a choice between TCP-like or TFRC-like congestion control, and that offers ECN, then this might be highly satisfactory to many application designers.
A key disadvantage of providing congestion control above UDP is that it places an unnecessary burden on the application-level designer, who might be just as happy to use the congestion control provided by a lower layer. If the application can rely on a lower layer that gives a choice between TCP-like or TFRC-like congestion control, and that offers ECN, then this might be highly satisfactory to many application designers.
The long history of debugging TCP implementations [RFC2525, PF01] makes the difficulties in implementing end-to-end congestion control abundantly clear. It is clearly more robust for congestion control to be provided for the application by a lower layer. In rare cases, there might be compelling reasons for the congestion control mechanism to be implemented in the application itself, but we do not expect this to be the general case. For example, applications that use RTP over UDP might be just as happy if RTP itself implemented end-to-end congestion control. (See Section 3.3.3 for more discussion of RTP.)
The long history of debugging TCP implementations [RFC2525, PF01] makes the difficulties in implementing end-to-end congestion control abundantly clear. It is clearly more robust for congestion control to be provided for the application by a lower layer. In rare cases, there might be compelling reasons for the congestion control mechanism to be implemented in the application itself, but we do not expect this to be the general case. For example, applications that use RTP over UDP might be just as happy if RTP itself implemented end-to-end congestion control. (See Section 3.3.3 for more discussion of RTP.)
In addition to congestion control issues, we also note the problems with firewall traversal and parameter negotiation discussed in Sections 2.3 and 2.4. Implementing on top of UDP requires that the application designer also address these issues.
In addition to congestion control issues, we also note the problems with firewall traversal and parameter negotiation discussed in Sections 2.3 and 2.4. Implementing on top of UDP requires that the application designer also address these issues.
3.1.2. Difficulties with ECN
3.1.2. Difficulties with ECN
There is a second problem with providing congestion control above UDP: it would require either giving up the use of ECN or giving the application direct control over setting and reading the ECN field in the IP header. Giving up the use of ECN would be problematic, since ECN can be particularly useful for unreliable flows, where a dropped packet will not be retransmitted by the data sender.
There is a second problem with providing congestion control above UDP: it would require either giving up the use of ECN or giving the application direct control over setting and reading the ECN field in the IP header. Giving up the use of ECN would be problematic, since ECN can be particularly useful for unreliable flows, where a dropped packet will not be retransmitted by the data sender.
Floyd, et al. Informational [Page 8] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 8] RFC 4336 Problem Statement for DCCP March 2006
With the development of the ECN nonce, ECN can be useful even in the absence of network support. The data sender can use the ECN nonce, along with feedback from the data receiver, to verify that the data receiver is correctly reporting all lost packets. This use of ECN can be particularly useful for an application using unreliable delivery, where the receiver might otherwise have little incentive to report lost packets.
With the development of the ECN nonce, ECN can be useful even in the absence of network support. The data sender can use the ECN nonce, along with feedback from the data receiver, to verify that the data receiver is correctly reporting all lost packets. This use of ECN can be particularly useful for an application using unreliable delivery, where the receiver might otherwise have little incentive to report lost packets.
In order to allow the use of ECN by a layer above UDP, the UDP socket would have to allow the application to control the ECN field in the IP header. In particular, the UDP socket would have to allow the application to specify whether or not the ECN-Capable Transport (ECT) codepoints should be set in the ECN field of the IP header.
In order to allow the use of ECN by a layer above UDP, the UDP socket would have to allow the application to control the ECN field in the IP header. In particular, the UDP socket would have to allow the application to specify whether or not the ECN-Capable Transport (ECT) codepoints should be set in the ECN field of the IP header.
The ECN contract is that senders who set the ECT codepoint must respond to Congestion Experienced (CE) codepoints by reducing their sending rates. Therefore, the ECT codepoint can only safely be set in the packet header of a UDP packet if the following is guaranteed:
The ECN contract is that senders who set the ECT codepoint must respond to Congestion Experienced (CE) codepoints by reducing their sending rates. Therefore, the ECT codepoint can only safely be set in the packet header of a UDP packet if the following is guaranteed:
o if the CE codepoint is set by a router, the receiving IP layer
will pass the CE status to the UDP layer, which will pass it to
the receiving application at the data receiver; and
o if the CE codepoint is set by a router, the receiving IP layer will pass the CE status to the UDP layer, which will pass it to the receiving application at the data receiver; and
o upon receiving a packet that had the CE codepoint set, the
receiving application will take the appropriate congestion control
action, such as informing the data sender.
o upon receiving a packet that had the CE codepoint set, the receiving application will take the appropriate congestion control action, such as informing the data sender.
However, the UDP implementation at the data sender has no way of knowing if the UDP implementation at the data receiver has been upgraded to pass a CE status up to the receiving application, let alone whether or not the application will use the conformant end-to- end congestion control that goes along with use of ECN.
However, the UDP implementation at the data sender has no way of knowing if the UDP implementation at the data receiver has been upgraded to pass a CE status up to the receiving application, let alone whether or not the application will use the conformant end-to- end congestion control that goes along with use of ECN.
In the absence of the widespread deployment of mechanisms in routers to detect flows that are not using conformant congestion control, allowing applications arbitrary control of the ECT codepoints for UDP packets would seem like an unnecessary opportunity for applications to use ECN while evading the use of end-to-end congestion control. Thus, there is an inherent "chicken-and-egg" problem of whether first to deploy policing mechanisms in routers, or first to enable the use of ECN by UDP flows. Without the policing mechanisms in routers, we would not advise adding ECN-capability to UDP sockets at this time.
In the absence of the widespread deployment of mechanisms in routers to detect flows that are not using conformant congestion control, allowing applications arbitrary control of the ECT codepoints for UDP packets would seem like an unnecessary opportunity for applications to use ECN while evading the use of end-to-end congestion control. Thus, there is an inherent "chicken-and-egg" problem of whether first to deploy policing mechanisms in routers, or first to enable the use of ECN by UDP flows. Without the policing mechanisms in routers, we would not advise adding ECN-capability to UDP sockets at this time.
In the absence of more fine-grained mechanisms for dealing with a period of sustained congestion, one possibility would be for routers to discontinue using ECN with UDP packets during the congested period, and to use ECN only with TCP or DCCP packets. This would be a reasonable response, for example, if TCP or DCCP flows were found
In the absence of more fine-grained mechanisms for dealing with a period of sustained congestion, one possibility would be for routers to discontinue using ECN with UDP packets during the congested period, and to use ECN only with TCP or DCCP packets. This would be a reasonable response, for example, if TCP or DCCP flows were found
Floyd, et al. Informational [Page 9] RFC 4336 Problem Statement for DCCP March 2006
Floyd, et al. Informational [Page 9] RFC 4336 Problem Statement for DCCP March 2006
to be more likely to be using conformant end-to-end congestion control than were UDP flows. If routers were to adopt such a policy, then DCCP flows could be more likely to receive the benefits of ECN in times of congestion than would UDP flows.
to be more likely to be using conformant end-to-end congestion control than were UDP flows. If routers were to adopt such a policy, then DCCP flows could be more likely to receive the benefits of ECN in times of congestion than would UDP flows.
3.1.3. The Evasion of Congestion Control
3.1.3. The Evasion of Congestion Control
A third problem of providing congestion control above UDP is that relying on congestion control at the application level makes it somewhat easier for some users to evade end-to-end congestion control. We do not claim that a transport protocol such as DCCP would always be implemented in the kernel, and do not attempt to evaluate the relative difficulty of modifying code inside the kernel vs. outside the kernel in any case. However, we believe that putting the congestion control at the transport level rather than at the application level makes it just slightly less likely that users will go to the trouble of modifying the code in order to avoid using end- to-end congestion control.
A third problem of providing congestion control above UDP is that relying on congestion control at the application level makes it somewhat easier for some users to evade end-to-end congestion control. We do not claim that a transport protocol such as DCCP would always be implemented in the kernel, and do not attempt to evaluate the relative difficulty of modifying code inside the kernel vs. outside the kernel in any case. However, we believe that putting the congestion control at the transport level rather than at the application level makes it just slightly less likely that users will go to the trouble of modifying the code in order to avoid using end- to-end congestion control.
3.2. Providing Congestion Control Below UDP
3.2. Providing Congestion Control Below UDP
Instead of providing congestion control above UDP, a second possibility would be to provide congestion control for unreliable applications at a layer below UDP, with applications using UDP as their transport protocol. Given that UDP does not itself provide sequence numbers or congestion feedback, there are two possible forms for this congestion feedback:
Instead of providing congestion control above UDP, a second possibility would be to provide congestion control for unreliable applications at a layer below UDP, with applications using UDP as their transport protocol. Given that UDP does not itself provide sequence numbers or congestion feedback, there are two possible forms for this congestion feedback:
1) Feedback at the application: The application above UDP could
provide sequence numbers and feedback to the sender, which would
then communicate loss information to the congestion control
mechanism. This is the approach currently standardized by the
Congestion Manager (CM) [RFC3124].
1) Feedback at the application: The application above UDP could provide sequence numbers and feedback to the sender, which would then communicate loss information to the congestion control mechanism. This is the approach currently standardized by the Congestion Manager (CM) [RFC3124].
2) Feedback at the layer below UDP: The application could use UDP,
and a protocol could be implemented using a shim header between IP
and UDP to provide sequence number information for data packets
and return feedback to the data sender. The original proposal for
the Congestion Manager [BRS99] suggested providing this layer for
applications that did not have their own feedback about dropped
packets.
2) UDPの下の層でのフィードバック: アプリケーションはUDPを使用するかもしれません、そして、一連番号情報をデータ・パケットに提供して、データ送付者にフィードバックを返すのにIPとUDPの間の詰め物のヘッダーを使用することでプロトコルは実装することができるでしょう。 Congestionマネージャ[BRS99]のための起案は、下げられたパケットに関するそれら自身のフィードバックを持っていなかったアプリケーションにこの層を提供するのを示しました。
We discuss these two cases separately below.
私たちは別々に以下でこれらの2つのケースについて議論します。
Floyd, et al. Informational [Page 10] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[10ページ]のRFC4336問題声明
3.2.1. Case 1: Congestion Feedback at the Application
3.2.1. ケース1: アプリケーションにおける混雑フィードバック
In this case, the application provides sequence numbers and congestion feedback above UDP, but communicates that feedback to a congestion manager below UDP, which regulates when packets can be sent. This approach suffers from most of the problems described in Section 3.1, namely, forcing the application designer to reinvent the wheel each time for packet formats and parameter negotiation, and problems with ECN usage, firewalls, and evasion.
アプリケーションは、この場合UDPの上で一連番号と混雑にフィードバックを提供しますが、UDPの下でそのフィードバックを混雑マネージャに伝えます、いつを規制するもの。パケットを送ることができます。 このアプローチはすなわち、アプリケーション設計者をその都度パケット・フォーマット、パラメタ交渉、および問題によって電子証券取引ネットワーク用法、ファイアウォール、および回避でわざわざ一からやり直させることにおけるセクション3.1で説明された問題の大部分に苦しみます。
It would avoid the application writer needing to implement the control part of the congestion control mechanism, but it is unclear how easily multiple congestion control algorithms (such as receiver- based TFRC) can be supported, given that the form of congestion feedback usually needs to be closely coupled to the congestion control algorithm being used. Thus, this design limits the choice of congestion control mechanisms available to applications while simultaneously burdening the applications with implementations of congestion feedback.
それはコントロールが混雑制御機構の一部であると実装する必要があるアプリケーション作家を避けるでしょうが、どうしたら、容易に複数の輻輳制御アルゴリズム(受信機ベースのTFRCなどの)をサポートすることができるかは不明瞭です、混雑フィードバックのフォームが、通常密接に使用される輻輳制御アルゴリズムと結合される必要があるなら。 したがって、このデザインは同時に混雑フィードバックの実装でアプリケーションを負担している間、アプリケーションに利用可能な混雑制御機構の選択を制限します。
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP
3.2.2. ケース2: UDPの下の層での混雑フィードバック
Providing feedback at a layer below UDP would require an additional packet header below UDP to carry sequence numbers in addition to the 8-byte header for UDP itself. Unless this header were an IP option (which is likely to cause problems for many IPv4 routers), its presence would need to be indicated using a different IP protocol value from UDP. Thus, the packets would no longer look like UDP on the wire, and the modified protocol would face deployment challenges similar to those of an entirely new protocol.
UDPの下の層でフィードバックを提供するのは、UDPの下の追加パケットのヘッダーがUDP自身のための8バイトのヘッダーに加えて一連番号を運ぶのを必要とするでしょう。 このヘッダーがIPオプション(多くのIPv4ルータのために問題を起こしそうである)でないなら、存在は、UDPと異なったIPプロトコル価値を使用することで示される必要があるでしょうに。 したがって、パケットはもうワイヤの上のUDPに似ていないでしょう、そして、変更されたプロトコルは完全に新しいプロトコルのものと同様の展開難局に直面しているでしょう。
To use congestion feedback at a layer below UDP most effectively, the semantics of the UDP socket Application Programming Interface (API) would also need changing, both to support a late decision on what to send and to provide access to sequence numbers (so that the application wouldn't need to duplicate them for its own purposes). Thus, the socket API would no longer look like UDP to end hosts. This would effectively be a new transport protocol.
また、UDPの下の層で最も効果的に混雑フィードバックを使用するために、UDPソケットApplication Programming Interface(API)の意味論は、ともに送るべきものに関する遅い決定をサポートして、一連番号へのアクセスを提供するために変化する必要があるでしょう(アプリケーションがそれ自身の目的のためにそれらをコピーする必要はないように)。 したがって、ソケットAPIはもう終わりのホストにUDPに似ていないでしょう。 事実上、これは新しいトランスポート・プロトコルでしょう。
Given these complications, it seems cleaner to actually design a new transport protocol, which also allows us to address the issues of firewall traversal, flow setup, and parameter negotiation. We note that any new transport protocol could also use a Congestion Manager approach to share congestion state between flows using the same congestion control algorithm, if this were deemed to be desirable.
これらの複雑さを考えて、実際に、新しいトランスポート・プロトコルを設計するのは、よりきれいに思えます。(また、私たちはトランスポート・プロトコルでファイアウォール縦断、流れセットアップ、およびパラメタ交渉の問題を扱うことができます)。 私たちは、また、どんな新しいトランスポート・プロトコルも同じ輻輳制御アルゴリズムを使用することで流れの間の混雑状態を共有するのにCongestionマネージャアプローチを使用するかもしれないことに注意します、これが望ましいと考えられたなら。
Floyd, et al. Informational [Page 11] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[11ページ]のRFC4336問題声明
3.3. Providing Congestion Control at the Transport Layer
3.3. トランスポート層で輻輳制御を提供します。
The concerns from the discussions above have convinced us that the best way to provide congestion control to applications that currently use UDP is to provide congestion control at the transport layer, in a transport protocol used as an alternative to UDP. One advantage of providing end-to-end congestion control in an unreliable transport protocol is that it could be used easily by a wide range of the applications that currently use UDP, with minimal changes to the application itself. The application itself would not have to provide the congestion control mechanism, or even the feedback from the data receiver to the data sender about lost or marked packets.
上の議論からの関心は、現在UDPを使用するアプリケーションに輻輳制御を提供する最も良い方法がトランスポート層で輻輳制御を提供することであると私たちを説得しました、UDPに代わる手段として使用されるトランスポート・プロトコルで。 終わりからエンドへの輻輳制御を頼り無いトランスポート・プロトコルに提供する1つの利点は現在UDPを使用するさまざまなアプリケーションで容易にそれを使用できるだろうということです、アプリケーション自体への最小量の変化で。 アプリケーション自体は無くなっているか著しいパケットに関してデータ受信装置からデータ送付者まで混雑制御機構、またはフィードバックさえ提供する必要はないでしょう。
The question then arises of whether to adapt TCP for use by unreliable applications, to use an unreliable variant of the Stream Control Transmission Protocol (SCTP) or a version of RTP with built- in congestion control, or to design a new transport protocol.
そして、質問は使用のために頼り無いアプリケーションでTCPを適合させるか、混雑で組立のコントロールと共にStream Control Transmissionプロトコル(SCTP)の頼り無い異形かRTPのバージョンを使用するか、または新しいトランスポート・プロトコルを設計するかが起こります。
As we argue below, the desire for minimal overhead results in the design decision to use a transport protocol containing only the minimal necessary functionality, and to leave other functionality such as reliability, semi-reliability, or Forward Error Correction (FEC) to be layered on top.
私たちが以下で論争するように、最小量のオーバーヘッドに関する願望は最小量の必要な機能性だけを含むトランスポート・プロトコルを使用して、先端で層にされるために信頼性、準の信頼性、またはForward Error Correctionなどの他の機能性を(FEC)に残すというデザイン決定をもたらします。
3.3.1. Modifying TCP?
3.3.1. TCPを変更しますか?
One alternative might be to create an unreliable variant of TCP, with reliability layered on top for applications desiring reliable delivery. However, our requirement is not simply for TCP minus in- order reliable delivery, but also for the application to be able to choose congestion control algorithms. TCP's feedback mechanism works well for TCP-like congestion control, but is inappropriate (or at the very least, inefficient) for TFRC. In addition, TCP sequence numbers are in bytes, not datagrams. This would complicate both congestion feedback and any attempt to allow the application to decide, at transmission time, what information should go into a packet. Finally, there is the issue of whether a modified TCP would require a new IP protocol number as well; a significantly modified TCP using the same IP protocol number could have unwanted interactions with some of the middleboxes already deployed in the network.
1つの選択肢はTCPの頼り無い異形を作成することであるかもしれません、信頼性が信頼できる配信を望んでいるアプリケーションのために先端で層にされている状態で。 しかしながら私たちの要件が単にコネを引いたTCPが信頼できる配信を命令するからであるアプリケーションが輻輳制御アルゴリズムTCPのフィードバック・メカニズムを選ぶことができるのが、TCPのような輻輳制御にうまくいきますが、また不適当でもある、(少なくとも、効率の悪い、)、TFRCのために。 さらに、TCP一連番号がデータグラムではなく、バイトであります。これは混雑フィードバックとアプリケーションが、トランスミッション時にどんな情報がパケットに入るべきであるかを決めるのを許容するどんな試みの両方も複雑にするでしょう。 最終的に、変更されたTCPがまた、新しいIPプロトコル番号を必要とするだろうかどうかに関する問題があります。 同じIPプロトコル番号を使用するかなり変更されたTCPはネットワークで既に配布されるいくらかのmiddleboxesとの求められていない相互作用を持つことができました。
It seems best simply to leave TCP as it is, and to create a new congestion control protocol for unreliable transfer. This is especially true since any change to TCP, no matter how small, takes an inordinate amount of time to standardize and deploy, given TCP's importance in the current Internet and the historical difficulty of getting TCP implementations right.
現状通り単にTCPを残して、頼り無い転送のために新しい混雑制御プロトコルを作成するのは最も良く思えます。 TCPへのどんな変化もどんなに小さくても標準化して、配布する途方もない時間を取るので、これは特に本当です、現在のインターネットにおけるTCPの重要性とTCP実装が正しくなるという歴史的な困難を考えて。
Floyd, et al. Informational [Page 12] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[12ページ]のRFC4336問題声明
3.3.2. Unreliable Variants of SCTP?
3.3.2. SCTPの頼り無い異形?
SCTP, the Stream Control Transmission Protocol [RFC2960], was in part designed to accommodate multiple streams within a single end-to-end connection, modifying TCP's semantics of reliable, in-order delivery to allow out-of-order delivery. However, explicit support for multiple streams over a single flow at the transport layer is not necessary for an unreliable transport protocol such as DCCP, which of necessity allows out-of-order delivery. Because an unreliable transport does not need streams support, applications should not have to pay the penalties in terms of increased header size that accompany the use of streams in SCTP.
SCTP(Stream Control Transmissionプロトコル[RFC2960])はただ一つの終わりから終わりとの接続の中に複数のストリームを収容するように一部設計されました、不適切な配送を許すようにTCPの信頼できて、注文している配送の意味論を変更して。 しかしながら、トランスポート層のただ一つの流れの上の複数のストリームの明白なサポートはDCCPなどの頼り無いトランスポート・プロトコルに必要でない、どれ、必要である、不適切な配送を許すか。 頼り無い輸送がそうしないので、必要性はサポートを流して、アプリケーションはSCTPにおけるストリームの使用に伴う増強されたヘッダーサイズに関する罰金を支払う必要はないはずです。
The basic underlying structure of the SCTP packet, of a common SCTP header followed by chunks for data, SACK information, and so on, is motivated by SCTP's goal of accommodating multiple streams. However, this use of chunks comes at the cost of an increased header size for packets, as each chunk must be aligned on 32-bit boundaries, and therefore requires a fixed-size 4-byte chunk header. For example, for a connection using ECN, SCTP includes separate control chunks for the Explicit Congestion Notification Echo (ECNE) and Congestion Window Reduced (CWR) functions, with the ECNE and CWR chunks each requiring 8 bytes. As another example, the common header includes a 4-byte verification tag to validate the sender.
複数のストリームを収容するというSCTPの目標によってSCTPパケット、塊がデータのためにあとに続いた一般的なSCTPヘッダーの基本的な基底構造(SACK情報など)は、動機づけられています。しかしながら、塊のこの使用はパケットに増強されたヘッダーサイズの費用で来ます、各塊が32ビットの境界で並べなければならなくて、したがって、固定サイズの4バイトの塊ヘッダーを必要とします。 例えば、電子証券取引ネットワークを使用している接続のためにSCTPはExplicit Congestion Notification Echo(ECNE)とCongestion Window Reduced(CWR)機能のための別々のコントロール塊を含んでいます、ECNEとCWR塊がそれぞれ8バイトを必要とすることで。 別の例として、一般的なヘッダーは、送付者を有効にするために4バイトの検証タグを入れます。
As a second concern, SCTP as currently specified uses TCP-like congestion control, and does not provide support for alternative congestion control algorithms such as TFRC that would be more attractive to some of the applications currently using UDP flows. Thus, the current version of SCTP would not meet the requirements for a choice between forms of end-to-end congestion control.
2番目の関心として、現在指定されているとしてのSCTPは、TCPのような輻輳制御を使用して、UDP流れを使用することで現在アプリケーションのいくつかにより魅力的なTFRCなどの代替の輻輳制御アルゴリズムのサポートを提供しません。 したがって、SCTPの最新版は終わりからエンドへの輻輳制御のフォームの選択のために条件を満たさないでしょう。
Finally, the SCTP Partial Reliability extension [RFC3758] allows a sender to selectively abandon outstanding messages, which ceases retransmissions and allows the receiver to deliver any queued messages on the affected streams. This service model, although well-suited for some applications, differs from, and provides the application somewhat less flexibility than, UDP's fully unreliable service.
SCTP Partial Reliability拡張子[RFC3758]で、どれが、最終的に「再-トランスミッション」をやめて、受信機が影響を受けるストリームに関するどんな列に並ばせられたメッセージも提供するのを許容するかを選択的に送付者を傑出しているメッセージを捨てます。このサービスモデルは、UDPの完全に頼り無いサービスよりいくつかのアプリケーションに十分合っていますが、異なって、いくらか少ない柔軟性をアプリケーションに前提とします。
One could suggest adding support for alternative congestion control mechanisms as an option to SCTP, and adding a fully-unreliable variant that does not include the mechanisms for multiple streams. We would argue against this. SCTP is well-suited for applications that desire limited retransmission with multistream or multihoming support. Adding support for fully-unreliable variants, multiple congestion control profiles, and reduced single-stream headers would risk introducing unforeseen interactions and make further
人は、オプションとして代替の混雑制御機構のサポートをSCTPに加えて、複数のストリームのためにメカニズムを含んでいない完全に頼り無い異形を加えるのを示すことができました。私たちはこれについて反対の議論をするでしょう。 SCTPは「マルチ-ストリーム」がある限られた「再-トランスミッション」かマルチホーミングサポートを望んでいるアプリケーションに十分合っています。 完全に頼り無い異形、複数の輻輳制御プロフィール、および減少しているただ一つのストリームヘッダーのサポートが予期しない相互作用を導入して、危険を冒して、一層に作ると言い足します。
Floyd, et al. Informational [Page 13] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[13ページ]のRFC4336問題声明
modifications ever more difficult. We have chosen instead to implement a minimal protocol, designed for fully-unreliable datagram service, that provides only end-to-end congestion control and any other mechanisms that cannot be provided in a higher layer.
変更、かつて、より難しいです。 私たちは、終わりからエンドへの輻輳制御だけを提供する完全に頼り無いデータグラムサービスのために設計された最小量のプロトコルと、より高い層に提供できないいかなる他のメカニズムも実装するのを代わりに選びました。
3.3.3. Modifying RTP?
3.3.3. RTPを変更しますか?
Several of our target applications currently use RTP layered above UDP to transfer their data. Why not modify RTP to provide end-to-end congestion control?
私たちのいくつかの目標アプリケーションが現在、それらのデータを移すためにUDPの上で層にされたRTPを使用します。 なぜ終わりからエンドへの輻輳制御を提供するようにRTPを変更しませんか?
When RTP lives above UDP, modifying it to support congestion control might create some of the problems described in Section 3.1. In particular, user-level RTP implementations would want access to ECN bits in UDP datagrams. It might be difficult or undesirable to allow that access for RTP, but not for other user-level programs.
RTPがUDPの上に住むとき、混雑がコントロールであるとサポートするようにそれを変更すると、セクション3.1で説明された問題のいくつかが作成されるかもしれません。 特に、ユーザレベルRTP実装はUDPデータグラムで電子証券取引ネットワークビットへのアクセスを必要とするでしょう。RTPのためのそのアクセスを許しますが、他のユーザレベルプログラムのために少しも許容するのは、難しくもなくて、また望ましくなくもないかもしれません。
Kernel implementations of RTP would not suffer from this problem. In the end, the argument against modifying RTP is the same as that against modifying SCTP: Some applications, such as the export of flow information from routers, need congestion control but don't need much of RTP's functionality. From these applications' point of view, RTP would induce unnecessary overhead. Again, we would argue for a clean and minimal protocol focused on end-to-end congestion control.
RTPのカーネル実装はこの問題に苦しまないでしょう。 結局、RTPを変更することに対する議論はSCTPを変更することに対するそれと同じです: ルータからの流れ情報の輸出などのいくつかの応用は、輻輳制御を必要としますが、RTPの機能性の多くは必要としません。 これらのアプリケーションの観点から、RTPは不要なオーバーヘッドを引き起こすでしょう。 一方、私たちは終わらせる終わりにおける清潔で最小量のプロトコル集中している輻輳制御について賛成の議論をするでしょう。
RTP would commonly be used as a layer above any new transport protocol, however. The design of that new transport protocol should take this into account, either by avoiding undue duplication of information available in the RTP header, or by suggesting modifications to RTP, such as a reduced RTP header that removes any fields redundant with the new protocol's headers.
しかしながら、RTPは層として一般的にどんな新しいトランスポート・プロトコルを超えて使用されるでしょう。その新しいトランスポート・プロトコルのデザインはRTPヘッダーで利用可能な情報の過度の重複を避けるか、またはRTPへの変更を示すことによって、これを考慮に入れるべきです、新しいプロトコルのヘッダーと共に余分などんな野原も取り除く減少しているRTPヘッダーのように。
3.3.4. Designing a New Transport Protocol
3.3.4. 新しいトランスポート・プロトコルを設計します。
In the first half of this document, we have argued for providing congestion control at the transport layer as an alternative to UDP, instead of relying on congestion control supplied only above or below UDP. In this section, we have examined the possibilities of modifying SCTP, modifying TCP, and designing a new transport protocol. In large part because of the requirement for unreliable transport, and for accommodating TFRC as well as TCP-like congestion control, we have concluded that modifications of SCTP or TCP are not the best answer and that a new transport protocol is needed. Thus, we have argued for the need for a new transport protocol that offers unreliable delivery, accommodates TFRC as well as TCP-like congestion control, accommodates the use of ECN, and requires minimal overhead in packet size and in the state and CPU processing required at the data receiver.
私たちは、UDPに代わる手段としてトランスポート層で輻輳制御を提供するために混雑に依存することの代わりにこのドキュメントの前半にUDPの上、または、UDPだけの下で供給を統制するように主張しました。 このセクションで、TCPを変更して、新しいトランスポート・プロトコルを設計して、私たちはSCTPを変更する可能性を調べました。 主に頼り無い輸送、およびTCPのような輻輳制御と同様に親切なTFRCのための要件のために、私たちは、SCTPかTCPの変更が最も良い答えでなく、新しいトランスポート・プロトコルが必要であると結論を下しました。 したがって、私たちは、パケットサイズと状態で頼り無い配送を提供する新しいトランスポート・プロトコルの必要性について賛成の議論をして、TCPのような輻輳制御と同様にTFRCを収容して、電子証券取引ネットワークの使用を収容して、最小量のオーバーヘッドを必要とします、そして、CPU処理がデータ受信装置で必要です。
Floyd, et al. Informational [Page 14] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[14ページ]のRFC4336問題声明
4. Selling Congestion Control to Reluctant Applications
4. 気の進まないアプリケーションに輻輳制御を販売します。
The goal of this work is to provide general congestion control mechanisms that will actually be used by many of the applications that currently use UDP. This may include applications that are perfectly happy without end-to-end congestion control. Several of our design requirements follow from a desire to design and deploy a congestion-controlled protocol that is actually attractive to these "reluctant" applications. These design requirements include a choice between different forms of congestion control, moderate overhead in the size of the packet header, and the use of Explicit Congestion Notification (ECN) and the ECN nonce [RFC3540], which provide positive benefit to the application itself.
この仕事の目標は実際に現在UDPを使用するアプリケーションの多くで使用される一般的な混雑制御機構を提供することです。 これは終わりからエンドへの輻輳制御なしで完全に満足なアプリケーションを含むかもしれません。 私たちのいくつかの設計の品質が実際に魅力的な混雑で制御されたプロトコルを設計して、配布する願望から「気の進まない」これらのアプリケーションまで続きます。 これらの設計の品質は異なった形式の輻輳制御と、パケットのヘッダーのサイズ、およびExplicit Congestion Notificationの使用における適度のオーバーヘッド(電子証券取引ネットワーク)と電子証券取引ネットワーク一回だけ[RFC3540]の選択を含んでいます。(一回だけはアプリケーション自体への全くの利益を提供します)。
There will always be a few flows that are resistant to the use of end-to-end congestion control, preferring an environment where end- to-end congestion control is used by everyone else, but not by themselves. There has been substantial agreement [RFC2309, FF99] that in order to maintain the continued use of end-to-end congestion control, router mechanisms are needed to detect and penalize uncontrolled high-bandwidth flows in times of high congestion; these router mechanisms are colloquially known as "penalty boxes". However, before undertaking a concerted effort toward the deployment of penalty boxes in the Internet, it seems reasonable, and more effective, to first make a concerted effort to make end-to-end congestion control easily available to applications currently using UDP.
終わりからエンドへの輻輳制御の使用に抵抗力があるいくつかの流れがいつもあるでしょう、終わりまでのエンド輻輳制御が他の人皆によって使用されますが、自分たちで使用されるというわけではない環境を好んで。 ルータメカニズムが終わりからエンドへの輻輳制御の継続的な使用を維持するのに高い混雑の時代に非制御の高帯域流れを検出して、罰するのが必要であるという実質的な同意[RFC2309、FF99]がありました。 これらのルータメカニズムは「ペナルティボックス」として口語的に知られています。 しかしながら、インターネットでのペナルティボックスの展開のための協力を引き受ける前に、それは、最初にUDPを使用することで現在終わりからエンドへの輻輳制御を容易にアプリケーションに利用可能にするための協力をするように妥当で、より効果的に思えます。
5. Additional Design Considerations
5. 追加デザイン問題
This section mentions some additional design considerations that should be considered in designing a new transport protocol.
このセクションは新しいトランスポート・プロトコルを設計する際に考えられるべきであるいくつかの追加デザイン問題について言及します。
o Mobility: Mechanisms for multihoming and mobility are one area of
additional functionality that cannot necessarily be layered
cleanly and effectively on top of a transport protocol. Thus, one
outstanding design decision with any new transport protocol
concerns whether to incorporate mechanisms for multihoming and
mobility into the protocol itself. The current version of DCCP
[RFC4340] includes no multihoming or mobility support.
o 移動性: マルチホーミングと移動性のためのメカニズムは必ずトランスポート・プロトコルの上で清潔に有効に層にすることができるというわけではない追加機能性の1つの領域です。 したがって、どんな新しいトランスポート・プロトコルによる1つの傑出しているデザイン決定もマルチホーミングのためにメカニズムを組み込むか、そして、プロトコル自体への移動性に関係があります。 DCCP[RFC4340]の最新版はどんなマルチホーミングも移動性サポートも含んでいません。
o Defense against DoS attacks and spoofing: A reliable handshake for
connection setup and teardown offers protection against DoS and
spoofing attacks. Mechanisms allowing a server to avoid holding
any state for unacknowledged connection attempts or already-
finished connections offer additional protection against DoS
attacks. Thus, in designing a new transport protocol, even one
designed to provide minimal functionality, the requirements for
o DoS攻撃に対するディフェンスとスプーフィング: 接続設定と分解のための信頼できる握手はDoSに対する保護とスプーフィング攻撃を提供します。 サーバが不承認の接続試みか既に終わっている接続のためにどんな状態も保持するのを避けることができるメカニズムはDoS攻撃に対する追加保護を提供します。 その結果新しいトランスポート・プロトコルを設計することにおける最小量の機能性、要件を提供する設計された1つさえ
Floyd, et al. Informational [Page 15] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[15ページ]のRFC4336問題声明
providing defense against DoS attacks and spoofing need to be
considered.
DoS攻撃に対してディフェンスを提供して、スプーフィングは、考えられる必要があります。
o Interoperation with RTP: As Section 3.3.3 describes, attention
should be paid to any necessary or desirable changes in RTP when
it is used over the new protocol, such as reduced RTP headers.
o RTPとInteroperation: 新しいプロトコルの上でそれを使用するとき、セクション3.3.3が説明するように、RTPにおけるどんな必要であるか望ましい変化にも注意を向けるべきです、減少しているRTPヘッダーなどのように。
o API: Some functionality required by the protocol, or useful for
applications using the protocol, may require the definition of new
API mechanisms. Examples include allowing applications to decide
what information to put in a packet at transmission time, and
providing applications with some information about packet sequence
numbers.
o API: 何らかの機能性がプロトコルが必要です、またはプロトコルを使用するアプリケーションの役に立って、新しいAPIメカニズムの定義を必要とするかもしれません。例は、アプリケーションが、トランスミッション時にどんな情報をパケットに置いたらよいかを決めるのを許容して、パケット一連番号の何らかの情報をアプリケーションに提供するのを含んでいます。
o Interactions with NATs and firewalls: NATs and firewalls don't
interact well with UDP, with its lack of explicit flow setup and
teardown and, in practice, the lack of well-known ports for many
UDP applications. Some of these issues are application specific;
others should be addressed by the transport protocol itself.
o NATsとの相互作用とファイアウォール: NATsとファイアウォールはUDPとよく対話しません、明白な流れセットアップと分解の不足と実際には多くのUDPアプリケーションのためのウェルノウンポートの不足で。 これらの問題のいくつかがアプリケーション特有です。 他のものはトランスポート・プロトコル自体によって宛てられるべきです。
o Consider general experiences with unicast transport: A
Requirements for Unicast Transport/Sessions (RUTS) BOF was held at
the IETF meeting in December 1998, with the goal of understanding
the requirements of applications whose needs were not met by TCP
[RUTS]. Not all of those unmet needs are relevant to or
appropriate for a unicast, congestion-controlled, unreliable flow
of datagrams designed for long-lived transfers. Some are,
however, and any new protocol should address those needs and other
requirements derived from the community's experience. We believe
that this document addresses the requirements relevant to our
problem area that were brought up at the RUTS BOF.
o ユニキャスト輸送の一般的な経験を考えてください: Unicast Transport/セッション(RUTS)BOFのためのRequirementsは1998年12月にIETFミーティングで持たれていました、需要がTCP[RUTS]によって満たされなかったアプリケーションの要件を理解しているという目標のために。 ユニキャストに、それらのunmetの必要性のすべてが、関連しているか、または適切であるというわけではありません、長命の転送のために設計されたデータグラムの混雑で制御されて、頼り無い流れ。 しかしながら、或るものがあって、どんな新しいプロトコルも、それらが共同体の経験から得られた必要性と他の要件であると扱うべきです。 私たちは、このドキュメントがRUTS BOFで持って来られた私たちの問題領域に関連している要件を扱うと信じています。
6. Transport Requirements of Request/Response Applications
6. 要求/応答アプリケーションの輸送要件
Up until now, this document has discussed the transport and congestion control requirements of applications that generate long- lived, large flows of unreliable datagrams. This section discusses briefly the transport needs of another class of applications, those of request/response transfers where the response might be a small number of packets, with preferences that include both reliable delivery and a minimum of state maintained at the ends. The reliable delivery could be accomplished, for example, by having the receiver re-query when one or more of the packets in the response is lost. This is a class of applications whose needs are not well-met by either UDP or by TCP.
現在まで、このドキュメントは頼り無いデータグラムの長い送られて、大きい流れを生成するアプリケーションの輸送と輻輳制御要件について議論しました。このセクションは簡潔にもう1人のクラスのアプリケーションの輸送の必要性について論じて、要求/応答のものは応答が少ない数のパケットであるかもしれないところに移されます、終わりに維持された信頼できる配信と最小状態の両方を含んでいる好みで。 例えば、受信機に応答におけるパケットの1つ以上がいつ無くなるかを再質問させることによって、信頼できる配信を実行できるでしょう。 これは必要性がUDPかTCPによってよく会われないアプリケーションのクラスです。
Floyd, et al. Informational [Page 16] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[16ページ]のRFC4336問題声明
Although there is a legitimate need for a transport protocol for such short-lived reliable flows of such request/response applications, we believe that the overlap with the requirements of DCCP is almost non-existent and that DCCP should not be designed to meet the needs of these request/response applications. Areas of non-compatible requirements include the following:
そのような要求/応答アプリケーションのそのような短命な信頼できる流れのためのトランスポート・プロトコルに関する正統な必要性がありますが、私たちは、DCCPの要件とのオーバラップがほとんど実在しなく、DCCPがこれらの要求/応答アプリケーションの需要を満たすように設計されるべきでないと信じています。 非コンパチブル要件の領域は以下を含んでいます:
o Reliability: DCCP applications don't need reliability (and long-
lived applications that do require reliability are well-suited to
TCP or SCTP). In contrast, these short-lived request/response
applications do require reliability (possibly client-driven
reliability in the form of requesting missing segments of a
response).
o 信頼性: DCCPアプリケーションは信頼性を必要としません(信頼性を必要とする長い送られたアプリケーションはTCPかSCTPに十分合っています)。 対照的に、これらの短命な要求/応答アプリケーションは信頼性(応答のなくなったセグメントを要求する形のことによるとクライアント駆動の信頼性)を必要とします。
o Connection setup and teardown: Because DCCP is aimed at flows
whose duration is often unknown in advance, it addresses
interactions with NATs and firewalls by having explicit handshakes
for setup and teardown. In contrast, the short-lived
request/response applications know the transfer length in advance,
but cannot tolerate the additional delay of a handshake for flow
setup. Thus, mechanisms for interacting with NATs and firewalls
are likely to be completely different for the two sets of
applications.
o 接続設定と分解: DCCPは持続時間があらかじめしばしば未知である流れを目的とされるので、それはセットアップと分解のための明白な握手を持っていることによって、NATsとファイアウォールとの相互作用を扱います。 対照的に、短命な要求/応答アプリケーションは、あらかじめ転送の長さを知っていますが、流れセットアップのための握手の追加遅れを許容できません。 したがって、NATsとファイアウォールと対話するためのメカニズムは2セットのアプリケーションにおいて完全に異なる傾向があります。
o Congestion control mechanisms: The styles of congestion control
mechanisms and negotiations of congestion control features are
heavily dependent on the flow duration. In addition, the
preference of the request/response applications for a stateless
server strongly impacts the congestion control choices. Thus,
DCCP and the short-lived request/response applications have rather
different requirements both for congestion control mechanisms and
for negotiation procedures.
o 混雑制御機構: 混雑制御機構のスタイルと輻輳制御機能の交渉はずっしりと流れ持続時間に依存しています。 さらに、状態がないサーバの要求/応答アプリケーションの好みは強く輻輳制御選択に影響を与えます。 したがって、DCCPと短命な要求/応答アプリケーションには、混雑制御機構と交渉手順のためのかなり異なった要件があります。
7. Summary of Recommendations
7. 推薦の概要
Our problem statement has discussed the need for implementing congestion control for unreliable flows. Additional problems concern the need for low overhead, the problems of firewall traversal, and the need for reliable parameter negotiation. Our consideration of the problem statement has resulted in the following general recommendations:
私たちの問題声明は混雑が頼り無い流れのためのコントロールであると実装する必要性について議論しました。 追加問題は低いオーバーヘッドの必要性、ファイアウォール縦断の問題、および信頼できるパラメタ交渉の必要性に関係があります。 私たちの問題声明の考慮は以下の一般的な推薦をもたらしました:
o A unicast transport protocol for unreliable datagrams should be
developed, including mandatory, built-in congestion control,
explicit connection setup and teardown, reliable feature
negotiation, and reliable congestion feedback.
o 頼り無いデータグラムのためのユニキャストトランスポート・プロトコルは開発されるべきです、義務的で、内蔵の輻輳制御、明白な接続設定、分解、信頼できる特徴交渉、および信頼できる混雑フィードバックを含んでいて。
Floyd, et al. Informational [Page 17] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[17ページ]のRFC4336問題声明
o The protocol must provide a set of congestion control mechanisms
from which the application may choose. These mechanisms should
include, at minimum, TCP-like congestion control and a more
slowly-responding congestion control such as TFRC.
o プロトコルはアプリケーションが選ばれるかもしれない1セットの混雑制御機構を提供しなければなりません。 これらのメカニズムは最小の、そして、TCPのような混雑でコントロールとTFRCなどのゆっくりより応じている輻輳制御を含んでいるはずです。
o Important features of the connection, such as the congestion
control mechanism in use, should be reliably negotiated by both
endpoints.
o 接続の使用中の混雑制御機構などの重要な特徴は両方の終点によって確かに交渉されるべきです。
o Support for ECN should be included. (Applications could still
make the decision not to use ECN for a particular session.)
o 電子証券取引ネットワークのサポートは含まれるべきです。 (アプリケーションはまだ、特定のセッションに電子証券取引ネットワークを使用しないという決定をしているかもしれません。)
o The overhead must be low, in terms of both packet size and
protocol complexity.
o オーバーヘッドはパケットサイズとプロトコルの複雑さの両方で低いに違いありません。
o Some DoS protection for servers must be included. In particular,
servers can make themselves resistant to spoofed connection
attacks ("SYN floods").
o サーバのための何らかのDoS保護を含まなければなりません。 特に、サーバで自分たちは偽造している接続攻撃(「SYNフラッド」)に抵抗力があるようになる場合があります。
o Connection setup and teardown must use explicit handshakes,
facilitating transmission through stateful firewalls.
o statefulファイアウォールを通したトランスミッションを容易にして、接続設定と分解は明白な握手を使用しなければなりません。
In 2002, there was judged to be a consensus about the need for a new unicast transport protocol for unreliable datagrams, and the next step was then the consideration of more detailed architectural issues.
2002年に、頼り無いデータグラムのための新しいユニキャストトランスポート・プロトコルの必要性に関するコンセンサスがあると判断されました、そして、そして、次のステップは、より詳細な構造的な問題の考慮でした。
8. Security Considerations
8. セキュリティ問題
There are no security considerations for this document. It does discuss a number of security issues in the course of problem analysis, such as DoS resistance and firewall traversal. The security considerations for DCCP are discussed separately in [RFC4340].
このドキュメントのためのセキュリティ問題が全くありません。 それは問題分析の間に多くの安全保障問題について議論します、DoS抵抗やファイアウォール縦断のように。 別々に[RFC4340]でDCCPのためのセキュリティ問題について議論します。
9. Acknowledgements
9. 承認
We would like to thank Spencer Dawkins, Jiten Goel, Jeff Hammond, Lars-Erik Jonsson, John Loughney, Michael Mealling, and Rik Wade for feedback on earlier versions of this document. We would also like to thank members of the Transport Area Working Group and of the DCCP Working Group for discussions of these issues.
このドキュメントの以前のバージョンのフィードバックについてスペンサー・ダウキンズ、Jitenゴエル、ジェフ・ハモンド、ラース-エリック・イェンソン、ジョンLoughney、マイケルMealling、およびリク・ウェイドに感謝申し上げます。 また、これらの問題の議論についてTransport Area作業部会とDCCP作業部会のメンバーに感謝申し上げます。
Floyd, et al. Informational [Page 18] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[18ページ]のRFC4336問題声明
Informative References
有益な参照
[BRS99] Balakrishnan, H., Rahul, H., and S. Seshan, "An
Integrated Congestion Management Architecture for
Internet Hosts", SIGCOMM, Sept. 1999.
[BRS99]Balakrishnan、H.、Rahul、H.、およびS.Seshan、「インターネットホストのための統合混雑管理体系」、SIGCOMM、1999年9月。
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-
End Congestion Control in the Internet", IEEE/ACM
Transactions on Networking, August 1999.
[FF99] フロイド、S.、およびK.は落ちます、「インターネットでの終わりからエンドへの輻輳制御の使用を促進し」て、ネットワークでのIEEE/ACMトランザクション、1999年8月。
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior
of Web Servers", SIGCOMM 2001.
[PF01] PadhyeとJ.とS.フロイド、「ウェブサーバーのTCP働きを特定します」、SIGCOMM2001
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J., and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2309] ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(1998年4月)。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[RFC2326]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W.,
Griner, J., Heavens, I., Lahey, K., Semke, J., and B.
Volz, "Known TCP Implementation Problems", RFC 2525,
March 1999.
[RFC2525] パクソンとV.とオールマンとM.とドーソンとS.とフェナーとW.とGrinerとJ.と天とI.とレーヒーとK.とSemke、J.とB.フォルツ、「知られているTCP実装問題」、RFC2525、1999年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[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月)対パクソン
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion
Manager", RFC 3124, June 2001.
[RFC3124]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
[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月)。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Floyd, et al. Informational [Page 19] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[19ページ]のRFC4336問題声明
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer,
"TCP Friendly Rate Control (TFRC): Protocol
Specification", RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust
Explicit Congestion Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003.
[RFC3540]スプリング、N.、Wetherall、D.、およびD.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、2003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004.
[RFC3714] フロイド、S.、およびJ.ケンフ、「混雑に関するIAB心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho(M.、シェ、Q.、Tuexen、M.、およびP.コンラッド)は「制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流します」、RFC3758、2004年5月。
[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月。
[RUTS] Requirements for Unicast Transport/Sessions (RUTS)
BOF, Dec. 7, 1998. URL
"http://www.ietf.org/proceedings/98dec/43rd-ietf-
98dec-142.html".
[溝] ユニキャスト転炉、1998年12月7日輸送/セッション(溝)のための要件。 URL「 http://www.ietf.org/proceedings/98dec/43rd-ietf- 98dec-142.html。」
Floyd, et al. Informational [Page 20] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[20ページ]のRFC4336問題声明
Authors' Addresses
作者のアドレス
Sally Floyd ICSI Center for Internet Research (ICIR), International Computer Science Institute, 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIは米国を国際電子計算機科学協会、1947Center通り、600バークレー、Suiteカリフォルニア インターネット研究(ICIR)、94704の中心に置きます。
EMail: floyd@icir.org
メール: floyd@icir.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
マーク・ハンドレー・コンピュータサイエンス学部ユニバーシティ・カレッジロンドンガウアー・ストリートロンドンWC1E 6BTイギリス
EMail: M.Handley@cs.ucl.ac.uk
メール: M.Handley@cs.ucl.ac.uk
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディ・コーラー4531・C BoelterホールUCLAコンピュータサイエンス部のカリフォルニア90095ロサンゼルス(米国)
EMail: kohler@cs.ucla.edu
メール: kohler@cs.ucla.edu
Floyd, et al. Informational [Page 21] RFC 4336 Problem Statement for DCCP March 2006
フロイド、他 DCCP行進2006年の情報[21ページ]のRFC4336問題声明
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Floyd, et al. Informational [Page 22]
フロイド、他 情報[22ページ]
一覧
スポンサーリンク
