One document matched: draft-karagiannis-conex-throughput-exposure-03.txt
Differences from draft-karagiannis-conex-throughput-exposure-02.txt
ConEx G. Karagiannis
Internet-Draft University of Twente
Intended status: Experimental D. Papadimitriou
Expires: January 10, 2012 Alcatel-Lucent
July 10, 2011
Exposing Conex Throughput using non-TCP Feedback
draft-karagiannis-conex-throughput-exposure-03
Abstract
This draft proposes to relay throughput instead of congestion
back into the network in-band at the IP layer, such that the total
level of throughput is accessible to all IP devices along the path
followed by IP datagrams. 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 relay the throughput
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 10, 2012.
Karagiannis Expires January 10, 2012 [Page 1]
Internet-Draft Exposing Conex Throughput 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. Challenges and Requirements . . . . . . . . . . . . . . . . . 4
2.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3. Method of Exposing Conex Throughput using non-TCP Feedback . 6
3.1 Description of the Method . . . . . . . . . . . . . . . . 6
3.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . . 8
3.3. Conex Throughput Components . . . . . . . . . . . . . . . 8
3.3.1 Modified Senders . . . . . . . . . . . . . . . . . . . 8
3.3.2 Intermediate Conex Enabled Devices . . . . . . . . . . 9
3.3.3 Modified Receivers . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 10
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . .10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Karagiannis Expires January 10, 2012 [Page 2]
Internet-Draft Exposing Conex Throughput July 2011
1. Introduction
The ConEx working group is defining how IP packets will carry
additional ConEx information. This document is focusing on relaying
throughput instead of congestion information back into the network
in-band at the IP layer. By this mean, the total level of throughput
is visible to all IP devices along the path.
In [draft-ietf-conex-abstract-mech-01] a method is described that
relies on following sequence of operation (1) using ECN marks and
packet drops the receiver computes the end-to-end path congestion,
(2) the receiver feeds this congestion information back to the
sender using TCP transport protocol, see also [draft-kuehlewind-
conex-accurate-ecn-00] (3) the sender 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 IP devices along the path.
This draft proposes to relay throughput instead of congestion
back into the network in-band at the IP layer, such that the total
level of throughput is visible to all IP devices along the path. For
this purpose, the proposed technique relies on another method to feed
congestion information back to the sender by using a non-TCP protocol
such as the DCCP (Datagram Congestion Control Protocol) transport
protocol instead of using the TCP transport protocol. The
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 the throughput experienced on the end-to-end path
back into the network.
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].
In addition to the terminology specified in [draft-ietf-conex-
abstract-mech-01] and [draft-ietf-conex-concepts-uses-01], [RFC5348]
the following terms are used and defined in this document.
Karagiannis Expires January 10, 2012 [Page 3]
Internet-Draft Exposing Conex Throughput July 2011
O Transport path throughput calculated at the sender: the per flow
transport sending rate as a function of the congestion rate,
round-trip time, and segment size. The transport path throughput
calculated at the sender can be realized using different methods.
As example, this draft uses as example the TCP throughput
equation that is specified in [RFC5348]. Note that in [RFC5348]
the term congestion rate is denoted as loss event rate. According
to [RFC5348] a loss event is defined as one or more lost or marked
packets from a window of data, where a marked packet refers to a
congestion indication (CE) from Explicit Congestion Notification
(ECN) [RFC3168];
O Throughput exposure signal (ConEx-Throughput): a ConEx signal
encoded in IP packet headers from the sender to the network to
exposure the transport path throughput calculated at the sender.
O Intermediate ConEx enabled device: each Conex enabled device
located on a communication path between a sender and a receiver.
O Measured per flow throughput at intermediate ConEx enabled devices:
the per flow rate of packets that are passing through the output
buffer of an intermediate Conex enabled device and
are not dropped, (2) are not ECN CE marked. Each ConEx enabled
device is only holding state on a flow if it first receives a
Throughput exposure signal.
O Throughput exposure rate at intermediate ConEx devices: the
per flow rate of the received throughput exposure signals (Conex-
Throughput). Each ConEx enabled device is only holding state on a
flow if it first receives a Throughput exposure signal (Conex-
Throughput).
2. Challenges and Requirements
2.1 Challenges
The challenges that need to be addressed by the throughput exposure
approach are:
o) The Internet operation has to enable multi-domain information
exchanges to effectively enable network-to-host information
passing as detailed in this document. This condition is of
particular importance for congestion control schemes that make use
of explicit rate feedback. On the other hand, multi-domain
environment shall be considered as non-cooperative.
Karagiannis Expires January 10, 2012 [Page 4]
Internet-Draft Exposing Conex Throughput July 2011
o) It is important to emphasize that network support of rate
signaling suffers from the same scalability problems as identified
in [RFC2208]. Indeed, in-band rate signaling or out-of-band per-
flow traffic specification signaling (like in the Resource
Reservation Protocol (RSVP)) results in similar scalability issues
due to the per-connection state maintenance. As noticed in Section
1 of [RFC6077], due to the non-cooperative nature of multi-domain
environments, it seems unlikely that network flow state could be
avoided (up to a certain extend) given the network's per-packet
flow rate instructions that would need to be compared against
variations in the actual flow rate, which is inherently not a per-
packet metric.
These issues have been outstanding ever since integrated services
(IntServ) was identified as unscalable in 1997 [RFC2208]. Any
subsequent attempt to involve network elements in limiting flow
rates (including XCP, RCP, etc.) have run up against the same
scalability issues when intending deployment on the
public/worldwide Internet.
o) Security is a challenge for multi-domain exchange of explicit
rate/congestion signals, whether in-band or out-of-band. At
domain boundaries, authentication and authorization issues can
arise whenever congestion control information is exchanged.
2.2 Requirements
The requirements the ConEx Signal shall meet in order to enable
throughput exposure, 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 throughput is represented accurately).
Note that in case of throughput exposure timeliness and accuracy
shall be bound by min;max limits in order to prevent non-significant
deviations (e.g. relative variations would be worth considering in
this respect).
Karagiannis Expires January 10, 2012 [Page 5]
Internet-Draft Exposing Conex Throughput July 2011
3. Method of Exposing Conex Throughput using non-TCP Feedback
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, (2) feedback 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 [RFC5622] or [RFC4342] (3)
calculate the sending throughput at the sender, (4) relaying the
throughput 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
throughput is visible to all IP devices along the path.
3.1 Description of the Method
The following paragraphs described each of the steps of the proposed
method:
1) During 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].
2) During 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 throughput for
the transport connection (to which the feedback is directed). The
path thoughput as computed by the sender describes the sending rate
as a function of the congestion rate (as computed by the receiver),
the round-trip time, and the segment size.
The transport path throughput calculated at the sender can be
accomplished using different algorithms. As example, the TCP
throughput equation specified in [RFC5348] or [RFC4828] can be
applied. Using the calculated throughput, the sender generates the
Conex throughput exposure signals that are encoded in IP packet
headers.
Karagiannis Expires January 10, 2012 [Page 6]
Internet-Draft Exposing Conex Throughput July 2011
4) In the fourth step, the Throughput exposure signals are relayed to
the network in-band at the IP layer, such that the total level of
throughput is visible to all IP devices along the path.
Each intermediate ConEx enabled device may hold a state to
store the value of the exposed throughput rate, which is
the per flow rate of the received throughput exposure signals (Conex-
Throughput). Each ConEx enabled device is only holding state on a
flow if it first receives a Throughput exposure signal (Conex-
Throughput). Note that the state information stored locally at Conex
enabled devices is "application dependent".
It is important to note that the per flow throughput measured by
intermediate ConEx enabled devices located closer to the sender can
be higher than the per flow throughput measured by Conex enabled
devices located closer to the receiver.
+---------+ +---------+
|Transport| +-----------+ |Transport|
| Sender |>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver|
| | | Network |>-Congestion-Signal->|---. (1) |
| | | Device | | | |
| | +-----------+ | | |
| | | | |
| |<==Feedback=Path==============================<| | |
| ,---|<--non-TCP returned Congestion Signal (2) ----<|<--' |
| V | | |
||-------|| | |
||Througp|| | |
|| || +-----------+ |Transport|
||calcul.||>=Data=Path=>|(Congested)|>=====Data=Path=====>| Receiver|
|| (3) |->(new)Conex->| Network |-(Throughp. signal)->| |
|+-------+| (4) | Device | (carried in data | |
| | +-----------+ packet headers) | |
+---------+ +---------+
Figure 1: Overview ConEx architecture, with Conex throughput
Exposure
Identical use cases and applications can be used as the ones
described in [draft-ietf-conex-concepts-uses-01], using the same
semantics related to the exposed and measured congestion. The only
difference is now that the intermediate Conex enabled devices can
monitor and process the "Measured per flow throughput" and the
"Throughput exposure rate", instead of monitoring and processing the
measured congestion rate and the signaled exposed congestion rate,
respectively.
Karagiannis Expires January 10, 2012 [Page 7]
Internet-Draft Exposing Conex Throughput July 2011
An example of applying this method, is to enable each intermediate
Congestion enabled device to observe whether the
"Measured per flow throughput" is equal or higher than the
"Throughput exposure rate" of the same flow.
If that is not the case then the intermediate Conex enabled devices
can react accordingly depending on the use case/application that uses
this solution.
{More details will be provided in a next version of this draft}
3.2. Codepoint Encoding
This encoding involves signaling the following codepoint:
o) Conex-Throughput: a ConEx signal encoded in IP packet headers from
the sender to the network to exposure the transport path throughput
calculated at the sender.
3.3. Conex Throughput Components
The same Conex enabled devices can be used as the ones specified in
[draft-ietf-conex-abstract-mech-01].
3.3.1 Modified Senders
The senders SHOULD support the protocol that is carrying the
throughput exposure information from the receiver to the sender.
Moreover, the sender should implement an algorithm that can use the
feedback congestion information to calculate the throughput 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 this case, the
sender MUST be able to support the following functionality:
O Computation of the transport path throughput: the per flow
transport sending rate as a function of the congestion rate, round-
trip time, and segment size. The transport path throughput
calculated at the sender using the TCP throughput equation
specified in [RFC5348]. Note that in [RFC5348] the term congestion
rate is denoted as loss event rate. According to [RFC5348] a loss
event is defined as one or more lost or marked packets from a
window of data, where a marked packet refers to a congestion
indication (CE) from Explicit Congestion Notification (ECN)
[RFC3168].
Karagiannis Expires January 10, 2012 [Page 8]
Internet-Draft Exposing Conex Throughput July 2011
In addition, the sender MUST be able to support the following
functionality:
o) Generation and encoding of ConEx-Throughput signals in IP packet
headers of datagrams flowing from the sender to the receiver in
order to expose the transport path throughput calculated at the
same sender.
3.3.2 Intermediate Conex Enabled Devices
The same intermediate Conex enabled devices MAY be used as the
intermediate Conex enabled devices specified in [draft-ietf-conex-
abstract-mech-01], e.g., Policer and Audit but not restricted to.
Compared to [draft-ietf-conex-abstract-mech-01], the only difference
introduced for the support of throughput exposure is
that i) the intermediate Conex enabled devices SHOULD monitor and ii)
the intermediate Conex enabled devices SHOULD process the "Measured
per flow throughput" and the "Throughput exposure rate", instead of
monitoring and processing the measured congestion rate and the
signaled exposed congestion rate, respectively.
3.3.3 Modified Receivers
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, the receivers should be able to support the TCP-Friendly
Rate Control (TFRC) based congestion control protocol, e.g.,
[RFC5348] (in combination with [RFC4342]) or [RFC4828] (in
combination with [RFC5622]).
In addition, the receiver MUST be able to support the following
functionality:
o) Measure per flow throughput: the per flow rate of packets that are
Received and (1) are not dropped, (2) are not ECN CE marked.
o) Measure throughput exposure rate: the
per flow rate of the received throughput exposure signals.
{More details on will be provided in a next version of this draft}
4. IANA Considerations
This memo includes no request to IANA.
Karagiannis Expires January 10, 2012 [Page 9]
Internet-Draft Exposing Conex Throughput July 2011
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The security consideration sections are the same as the security
considerations associated with [draft-ietf-conex-abstract-mech-01].
{More details will be provided in a next version of this draft>}
6. Conclusions
This draft proposes a method of exposing Conex throughput using non-
TCP Feedback.
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
9.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.
Karagiannis Expires January 10, 2012 [Page 10]
Internet-Draft Exposing Conex Throughput July 2011
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.
[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.
[RFC2208] Mankin, A., Ed., Baker, F., Braden,
B., Bradner, S., O'Dell, M.,
Romanow, A., Weinrib, A., and
L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1
Applicability Statement Some
Guidelines on Deployment",
RFC 2208, September 1997.
[RFC3168] K. Ramakrishnan, S. Floyd, S., and
D. Black, "The Addition of Explicit
Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[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.
Karagiannis Expires January 10, 2012 [Page 11]
Internet-Draft Exposing Conex Throughput July 2011
[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.
[RFC6077] D.Papadimitriou (Ed.), M.Welzl,
M.Scharf, B.Briscoe, Open Research
Issues in Internet Congestion
Control, RFC 6077, February 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 10, 2012 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 05:53:33 |