One document matched: draft-karagiannis-conex-congestion-calculation-02.txt
Differences from draft-karagiannis-conex-congestion-calculation-01.txt
ConEx G. Karagiannis
Internet-Draft University of Twente
Intended status: Experimental D. Papadimitriou
Expires: January 11, 2012 Alcatel-Lucent
July 11, 2011
Non-TCP based Feedback for Congestion Exposure
draft-karagiannis-conex-congestion-calculation-02
Abstract
This document describes a procedure that allows receivers to compute
the congestion from the received congestion information and to
communicate this information 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 11, 2012.
Karagiannis, Expires January 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
2. Method of congestion exposure using non-TCP related feedback 4
2.1. Congestion exposure method overview . . .. . . . . . . . 4
2.2. Requirements for the Conex signal . . . . .. . . . . . . 5
2.3. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 6
2.4. Conex Components . . . . . . . . . . . . . . . . . . . 6
2.4.1. Modified Senders . . . . . . . . . . . . . . . . . 6
2.4.2. Intermediate Conex Enabled Devices . . . . . . . 6
2.4.3. Modified Receivers . .. . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 8
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .8
8.1. Normative References . . . . . . . . . . . . . . . . . . .8
8.2. Informative References . . . . . . . . . . . . . . . . . .8
Karagiannis, Expires January 11, 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 procedure that allows receivers to compute the
congestion from the received congestion information and to
communicate this information 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.
This procedure is used as part of sequence of operation where (1) the
receiver using ECN marks and packet drops computes the end-to-end
path loss event rate, (2) the receiver feed this end-to-end path loss
event rate information back to the sender using a non-TCP transport
protocol, such as the DCCP transport protocol [RFC4340] together with
[RFC4342] or [RFC5622]. Subsequently, in (3) the sender computes the
congestion at the sender, and (4) relays 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 Conex Enabled IP devices along the path.
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 11, 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) the
sender computes the congestion at the sender, (4) 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 Conex Enabled 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->|---. (1) |
| | | Device | | | |
| | +-----------+ | | |
| | | | |
| |<==Feedback=Path==============================<| | |
| ,---|<-- returned Congestion Signal---------------<|<--' |
| V | (2) | |
||-------|| | |
||Congest|| | |
|| || +-----------+ |Transport|
||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver|
|| (3) |->(new)Conex->| Network |-(new)Conex signal)->| |
|+-------+| (4) | Device | (carried in data | |
| | +-----------+ packet headers) | |
+---------+ +---------+
Figure 1: Overview ConEx architecture, based on
[draft-ietf-conex-abstract-mech-01]
2.1. Congestion exposure method overview
The following paragraphs described each of the steps of the proposed
method:
1) In the first step, the end-to-end path
loss event rate is calculated at the receiver using ECN marks
and packet drops. This rate can be calculated using different
algorithms. As example, the loss event rate calculation specified in
[RFC5348] (in combination with [RFC4342]) or [RFC4828] (in
combination with [RFC5622]) can be used for this purpose. For a
normative specification of the loss event rate see Section 5 of
[RFC5348] and [RFC4828].
Karagiannis, Expires January 11, 2012 [Page 4]
Internet-Draft Congestion exposure using non-TCP July 2011
2) In the second step, the receiver sends this
end-to-end path loss event rate information back to the sender using
a non-TCP transport protocol, such as the DCCP transport protocol,
see [RFC4340], [RFC5622] or [RFC4342]. In this case, the receiver
reports using DCCP-Ack packets, among others, the number of loss
event rate by using the Loss event rate option, described in Section
8.5 of [RFC4342].
3) In the third step, the sender calculates the path congestion
at the sender (to which the feedback is directed). The congestion at
the sender is calculated using the congestion computed at the
receiver, e.g., the loss event rate. This step can be realized using
different algorithms, e.g., see [draft-ietf-conex-abstract-mech-01]).
Moreover, in this step the congestion exposure signals can be encoded
using the same method specified in [draft-ietf-conex-abstract-mech-
01]).
4) In the fourth step the congestion exposure signals are relayed
back into the network in-band at the IP layer, such that the total
level of congestion is visible to Conex Enabled IP devices along the
path. This information MAY also be relayed to non co-located traffic
managers.
Note that steps 1 and 2 are common with the Throughput exposure
approach documented in
[draft-karagiannis-conex-throughput-exposure-03]. Making this
approach common to both types of exposures.
2.2. 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).
Karagiannis, Expires January 11, 2012 [Page 5]
Internet-Draft Congestion exposure using non-TCP July 2011
2.3. Codepoint Encoding
An identical encoding is used as the one specified in [draft-ietf-
conex-abstract-mech-01].
2.4. Conex Components
The same Conex enabled devices can be used as the ones specified in
[draft-ietf-conex-abstract-mech-01].
2.4.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 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 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.4.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.4.3 Modified Receivers
The receiver SHOULD be able to calculate the congestion 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}
3. IANA Considerations
This memo includes no request to IANA.
Karagiannis, Expires January 11, 2012 [Page 6]
Internet-Draft Congestion exposure using non-TCP July 2011
4. Security Considerations
The security considerations described in
[draft-ietf-conex-abstract-mech-01] apply also for this document.
5. Conclusions
This draft proposes a method of exposing Conex congestion using non-
TCP Feedback.
6. Acknowledgements
We thank Richard Scheffenegger and Bob Briscoe for feedback on this
document.
7. 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.
8. References
8.1. Normative 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.
8.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 11, 2012 [Page 7]
Internet-Draft Congestion exposure using non-TCP July 2011
[draft-karagiannis-conex-throughput-exposure-03] G. Karagiannis,
D. Papadimitriou, "Exposing Conex
Throughput using non-TCP Feedback",
draft-karagiannis-conex-throughput-
exposure-03, Internet
draft (work in progress), 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 11, 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 11, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:54:01 |