One document matched: draft-karagiannis-conex-congestion-calculation-01.txt
Differences from draft-karagiannis-conex-congestion-calculation-00.txt
ConEx G. Karagiannis
Internet-Draft University of Twente
Intended status: Experimental D. Papadimitriou
Expires: January 8, 2012 Alcatel-Lucent
July 8, 2011
Non-TCP based Feedback for Congestion Exposure
draft-karagiannis-conex-congestion-calculation-01
Abstract
This document describes a solution used to feedback congestion
information calculated at the receiver, back to the sender using
non-TCP based protocols. The main advantage of this approach is that
applications that are not using the TCP protocol as transport
protocol could also apply the Conex concept to rely congestion
experienced on the end-to-end path back into the network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January, 2012.
Karagiannis, Expires January 08, 2012 [Page 1]
Internet-Draft Congestion exposure using non-TCP July 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .
2. Method of congestion exposure using non-TCP related feedback
2.1. Requirements for the Conex signal . . . . .. . . . . . . .
2.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . . .
2.3. Conex Components . . . . . . . . . . . . . . .
2.3.1. Modified Senders . . . . . . . . . . . . . . . . . . .
2.3.2. Intermediate Conex Enabled Devices . . . . . . . . .
2.3.3. Modified Receivers . .. . . . . . . . . . . . . . . .
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
4. Security Considerations . . . . . . . . . . . . . . . . . . .
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . .
8. Comments Solicited
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1. Normative References . . . . . . . . . . . . . . . . . . . .
9.2. Informative References . . . . . . . . . . . . . . . . . . .
Karagiannis, Expires January 08, 2012 [Page 2]
Internet-Draft Congestion exposure using non-TCP July 2011
1. Introduction
The ConEx working group is defining how IP packets will carry
additional ConEx information. This document describes a solution
used to feedback congestion information calculated at the receiver,
back to the sender using non-TCP based protocols.
In [draft-ietf-conex-abstract-mech-01] a method is described on (1)
using ECN marks and packet drops to calculate the end-to-end path
congestion at the receiver, (2) feedback this congestion information
back to the sender using the TCP transport protocol, see also [draft-
kuehlewind-conex-accurate-ecn-00] (3) relaying the congestion that
has been experienced on the end-to-end path back into the network
in-band at the IP layer, such that the total level of congestion is
visible to all IP devices along the path.
This draft specifies a solution used to feedback congestion
information calculated at the receiver, back to the sender using non-
TCP based protocols, instead of using the TCP transport protocol. The
main advantage of this approach is that applications that are not
using the TCP protocol as transport protocol could also apply the
Conex concept to rely congestion experienced on the end-to-end path
back into the network.
This solution uses three main steps: (1) using ECN marks and packet
drops to calculate the end-to-end path congestion at the receiver,
(2) feedbacking congestion information calculated at the receiver,
back to the sender by using non-TCP based protocols, for example DCCP
(Datagram Congestion Control Protocol)(3) relaying the congestion
that has been experienced on the end-to-end path back into the
network in-band at the IP layer, such that the total level of
congestion is visible to all IP devices along the path, (identical to
the same step specified in [draft-ietf-conex-abstract-mech-01]).
1.1 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 RFC 2119 [RFC2119].
The terminology specified in [draft-ietf-conex-
abstract-mech-01] and [draft-ietf-conex-concepts-uses-01], [RFC5348]
applies also for this document.
Karagiannis, Expires January 08, 2012 [Page 3]
Internet-Draft Congestion exposure using non-TCP July 2011
2. Method of using non-TCP related feedback for congestion exposure
This document provides a method, see Figure 1, on (1) using ECN marks
and packet drops to calculate the end-to-end path loss event rate at
the receiver, which is identical to the one specified in [draft-ietf-
conex-abstract-mech-01]), (2) feedbacking congestion information
calculated at the receiver, back to the sender by using non-TCP based
protocols, for example DCCP [RFC4340], [RFC5622], [RFC4342], (3)
relaying the congestion that has been experienced on the end-to-end
path back into the network in-band at the IP layer, such that the
total level of congestion is visible to all IP devices along the
path, which identical to the one specified in [draft-ietf-conex-
abstract-mech-01]).
+---------+ +---------+
|Transport| +-----------+ |Transport|
| Sender |>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver|
| | | Network |>-Congestion-Signal->|---. |
| | | Device | | | |
| | +-----------+ | | |
| | | | |
| |<==Feedback=Path==============================<| | |
| ,---|<-- returned Congestion Signal---------------<|<--' |
| V | | |
||-------|| | |
||Congest|| | |
||rate || +-----------+ |Transport|
||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver|
|| |->(new)Conex->| Network |-(new)Conex signal)->| |
|+-------+| | Device | (carried in data | |
| | +-----------+ packet headers) | |
+---------+ +---------+
Figure 1: Overview ConEx architecture, based on
[draft-ietf-conex-abstract-mech-01]
During the first step used by this method the end-to-end path
loss event rate at the receiver is calculated using ECN marks
and packet drops. This loss event rate can be calculated using
different algorithms. As example we mention the use of loss event
rate calculation specified in [RFC5348] (in combination with
[RFC4342]) or [RFC4828] (in combination with [RFC5622]). For a
normative specification of the loss event rate see (Section 5 of)
[RFC5348] and [RFC4828].
Karagiannis, Expires January 08, 2012 [Page 4]
Internet-Draft Congestion exposure using non-TCP July 2011
During the second step used by this method the receiver sends the
calculated congestion rate to the sender using a non-TCP transport
protocol. For example, if the non-TCP transport protocol is DCCP then
this step can be realized by the specification given in [RFC5622] or
[RFC4342]. In this case the receiver reports in DCCP-Ack packets,
among others, also the number of loss event rate by using the Loss
event rate option described in Section 8.5 of [RFC4342].
During the third step the congestion rate at the sender side needs to
be calculated from the received congestion information carried by the
feedback protocol. The description of how this congestion rate is
calculated is out of the scope of this I-D. After that the congestion
rate is calculated, an identical procedure is used as the one
specified in [draft-ietf-conex-abstract-mech-01] to encode the
Congestion exposure signals and to relay them back into the network
in-band at the IP layer, such that the total level of congestion is
visible to all IP devices along the path,
{More details will be included in a next version of this draft.}
2.1. Requirements for the ConEx Signal
The following requirements apply to the Conex exposure signal,
which are in line with most of the requirements presented in
[draft-ietf-conex-abstract-mech-01]:
o) The ConEx Signal SHOULD be visible to internetwork layer
devices along the entire path from the transport sender to the
transport receiver.
o) The ConEx Signal SHOULD be useful under only partial
deployment.
o) The ConEx Signal SHOULD be timely.
o) The ConEx Signal SHOULD be accurate (i.e., such that the
signaled congestion is represented accurately).
2.2. Codepoint Encoding
An identical encoding is used as the one specified in [draft-ietf-
conex-abstract-mech-01].
2.3. Conex Components
The same Conex enabled devices can be used as the ones specified in
[draft-ietf-conex-abstract-mech-01].
Karagiannis, Expires January 08, 2012 [Page 5]
Internet-Draft Congestion exposure using non-TCP July 2011
2.3.1 Modified Senders
The senders SHOULD support the protocol that is carrying the
congestion information from the receiver to the sender. Moreover, the
sender should implement an algorithm that can use the feedback
congestion information to calculate the congestion rate at the
sender. As example, if DCCP in combination with the TCP-Friendly Rate
Control (TFRC) is used, then the solutions specified in e.g.,
[RFC5348] (in combination with [RFC4342]) or [RFC4828] (in
combination with [RFC5622]) SHOULD be supported.
In addition, the sender MUST be able to encode the calculated
congestion rate at the sender into Conex Exposure Signals. This
latter procedure is the same as the same procedure used by [draft-
ietf-conex-abstract-mech-01].
2.3.2 Intermediate Conex Enabled Devices
The same intermediate Conex enabled devices could be used as the
intermediate Conex enabled devices specified in [draft-ietf-conex-
abstract-mech-01], e.g., Policer and Audit.
2.3.3 Modified Receivers
The receiver SHOULD be able to calculate the congestion rate at the
receiver, which needs to be forwarded at the sender.
Moreover, the receivers should be able to support the same transport
protocol supported by the sender used to feedback the calculated
congestion information from the receiver to the sender.
As example, if DCCP in combination with the TCP-Friendly Rate
Control (TFRC) is used then the solutions specified in e.g.,
[RFC5348] (in combination with [RFC4342]) or [RFC4828] (in
combination with [RFC5622]) SHOULD be applied.
{More details on will be provided in a next version of this draft}
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
The security considerations described in
[draft-ietf-conex-abstract-mech-01] apply also for this document.
Karagiannis, Expires January 08, 2012 [Page 6]
Internet-Draft Congestion exposure using non-TCP July 2011
6. Conclusions
{to be done}
7. Acknowledgements
We thank Richard Scheffenegger and Bob Briscoe for feedback on this
document.
8. Comments Solicited
Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Congestion Exposure (ConEx) working group
mailing list <conex@ietf.org>, and/or to the authors.
9. References
[draft-ietf-conex-abstract-mech-01] M. Mathis, B. Briscoe, "Congestion
Exposure (ConEx) Concepts and
Abstract Mechanism", draft-ietf-
conex-abstract-mech-01, (work in
progress), March 2011.
[RFC2119] S. Bradner, "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
9.2. Informative References
[draft-ietf-conex-concepts-uses-01] T. Moncaster, J. Leslie, B. Briscoe,
R. Woundy, D. McDysan, "ConEx
Concepts and Use Cases", draft-
ietf-conex-concepts-uses-01,
Internet draft, (Work
in progress), March 2011.
Karagiannis, Expires January 08, 2012 [Page 7]
Internet-Draft Congestion exposure using non-TCP July 2011
[draft-kuehlewind-conex-accurate-ecn-00] M. Kuehlewind,
R. Scheffenegger, "Accurate ECN
Feedback in TCP", draft-kuehlewind-
conex-accurate-ecn-00, Internet
draft (work in progress), July
2011.
[RFC4340] Kohler, E., Handley, M., and S.
Floyd, "Datagram Congestion Control
Protocol (DCCP)", RFC 4340, March
2006.
[RFC4342] Floyd, S., Kohler, E., and J.
Padhye, "Profile for Datagram
Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-
Friendly Rate Control (TFRC)", RFC
4342, March 2006.
[RFC4828] Floyd, S. and E. Kohler, "TCP
Friendly Rate Control (TFRC): The
Small-Packet (SP) Variant", RFC
4828, April 2007.
[RFC5348] S. Floyd, M. Handley, J. Padhye,
J. Widmer, "TCP Friendly Rate
Control (TFRC): Protocol
Specification", RFC 5348, September
2008.
[RFC5622] S. Floyd, E. Kohler, "Profile for
Datagram Congestion Control Protocol
(DCCP) Congestion ID 4: TCP-Friendly
Rate Control for Small Packets
(TFRC-SP)", RFC 5622, August 2009.
Karagiannis, Expires January 08, 2012 [Page 8]
Internet-Draft Congestion exposure using non-TCP July 2011
Authors' Addresses
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Dimitri Papadimitriou (editor)
Alcatel-Lucent
Copernicuslaan, 50
2018 Antwerpen, Belgium
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.com
Karagiannis, Expires January 08, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:54:01 |