[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                          E. Lochin
Internet-Draft                                    National ICT Australia
Expires: May 5, 2006                                         L. Dairaine
                                                                   NICTA
                                                        November 1, 2005


  Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network
                    draft-lochin-ietf-tsvwg-gtfrc-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo introduces gTFRC, a TCP-Friendly Rate Control providing
   throughput guarantee over the DiffServ/AF class. gTFRC is largely
   based on TFRC [2].  It provides a mean to take into account the
   quality of service negotiated with the network.  As a result, the
   mechanism is able to reach a minimum throughput guarantee whatever
   the flow's RTT and target rate.




Lochin & Dairaine          Expires May 5, 2006                  [Page 1]


Internet-Draft                    gTFRC                    November 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Guaranteed TCP Friendly Rate Control . . . . . . . . . . . . .  4
     2.1.  Transmit rate equation . . . . . . . . . . . . . . . . . .  4
     2.2.  Target rate default value  . . . . . . . . . . . . . . . .  4
     2.3.  Target rate setting  . . . . . . . . . . . . . . . . . . .  4
   3.  Simulation of gTFRC  . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Model and hypothesis . . . . . . . . . . . . . . . . . . .  5
     3.2.  Results  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10




































Lochin & Dairaine          Expires May 5, 2006                  [Page 2]


Internet-Draft                    gTFRC                    November 2005


1.  Introduction

   This memo introduces gTFRC, a TCP-Friendly rate control providing
   throughput guarantee for unicast flows over the DiffServ/AF class.
   gTFRC is an adaptation of the TCP-friendly Rate Control (TFRC) [2].
   This document only specifies the modification of TFRC and do not
   present the core TFRC mechanism that remain unchanged.

   TFRC is a congestion control mechanism for unicast flows operating in
   a best-effort Internet environment[2].  Based on the TCP throughput
   equation, it is designed to be reasonably fair when competing for
   bandwidth with TCP flow.  It generates a flow with a much lower
   variation of throughput over time than TCP.  As a result, it is
   particularly suitable for multimedia application such as video
   streaming or telephony over Internet.

   The DiffServ Assured Forwarding Class [1] has been designed to
   provide a guaranteed minimal throughput that many multimedia
   applications can take advantage of.  The service offers is called
   Assured Service (AS) and built over the AF PHB.  The minimum
   guaranteed throughput (also called target rate) is supposed to be
   known after a negotiation phase involving application level software.
   Adaptive application can make use of this guarantee, allowing to rely
   on a minimum rate when the network is congested, and possibly using
   higher rate otherwise.  In this service class, a congestion control
   is required in such a way to discover the current available bandwidth
   and share it fairly with other competing flows.  Nevertheless, due to
   the minimum bandwidth guarantee, the congestion control mechanism
   should never reduce the flow throughput at a value less than the
   negotiated guaranty.

   When TFRC is used over a DiffServ/AF network, in spite of a good
   behavior in term of available bandwidth sharing, it not always reach
   the target rate.  Even if the target rate is finally reached, a long
   time can happened (several tens of seconds) before the flow rate
   converges to this value.  Then, depending on end-to-end delay and the
   loss probability of the various connections, the application does not
   obtained the requested target rate it should, even if the underlying
   network provides an adequate throughput guarantee.

   This document suggests a simple approach to solve this problem.  A
   minimal adaption of TFRC allows the application to quickly reach its
   target rate whatever the RTT value of the application's flow, while
   still sharing fairly the available bandwidth over the various TCP-
   friendly connections.






Lochin & Dairaine          Expires May 5, 2006                  [Page 3]


Internet-Draft                    gTFRC                    November 2005


2.  Guaranteed TCP Friendly Rate Control

   In the context of the Additive Increase Multiplicative Decrease
   approaches like TCP, the only way to obtain a service differentiation
   with TCP protocol is to use DiffServ traffic conditioners.  Indeed,
   the AIMD principle do not use the instantaneous TCP throughput as an
   input value for its congestion control and then can not make direct
   use of the target rate value.  On the contrary, to compute the actual
   sending rate, TFRC uses the current rate in conjunction with the RTT
   and the loss event of flow.  Nevertheless, the TCP equation that
   drives TFRC does not take into account the minimum guaranteed part of
   the network capacity.

   gTFRC is made aware of the target rate value which is integrated into
   the transmit rate equation.  Thanks to this knowledge, the
   application's flow is sent in conformance with the negotiated QoS
   while staying TCP-friendly in its out-profile part.

2.1.  Transmit rate equation

   The transmit rate is computed at sender side as the maximum between
   the TFRC rate estimation and the target rate.  The throughput
   equation used in gTFRC is:

   G = max(g, X)

   Where:

      G is the transmit rate in bytes/second.

      g is the target rate in bytes/second.

      X is the transmit rate in bytes/second computed by the TCP
      throughput equation specified in RFC 3448 [2].

   The rest of the gTFRC mechanism follows entirely the TFRC
   specification given in RFC 3448 [2].

2.2.  Target rate default value

   The target rate g MUST have a default value of zero byte/second.  In
   this case, the default behavior of gTFRC corresponds to TFRC.

2.3.  Target rate setting

   gTFRC requires the knowledge of the target rate the DiffServ/AF
   network service provides to the session.  This knowledge MAY be
   achieved by the use of a new socket option.



Lochin & Dairaine          Expires May 5, 2006                  [Page 4]


Internet-Draft                    gTFRC                    November 2005


3.  Simulation of gTFRC

3.1.  Model and hypothesis

   gTFRC has been evaluated over a DiffServ network using ns-2.28
   simulator. gTFRC has been implemented from the TFRC ns-2 code base.
   The Nortel DiffServ model [3] has been used as QoS testbed.

   The network architecture is shown in the following figure.

   ----                                                        ----
   |s1|--------                                      --------- |r1|
   ----  10 Mb \                                    /  10 Mb   ----
         5 ms   \                                  /    x ms
                 \------       ------       ------/
                  |edge|-------|core|-------|edge|
                 /------       ------       ------\
                /        10 Mb          1 Mb       \
   ----        /          5 ms          10ms        \          ----
   |s2|--------                                      --------- |r2|
   ----  10 Mb                                         10 Mb   ----
          5 ms                                          y ms

   where x and y take different RTT values in function of the
   experiment.

   Figure 1

   In these experiments, the objective was to compare the performance of
   TFRC and gTFRC.

   The simulation has been achieved with the two following scenarios:

   1.  the network is exactly-provisioned (it means there is no excess
       bandwidth for the out-profile traffic).

   2.  network is over-provisioned (when there is excess bandwidth).

   A network is under-provisioned when the amount of in-profile traffic
   is higher than the resource allocated to the AF class.  This case is
   considered as a bad network provision and then is excluded from the
   field of this study.

   In the simulations:

   o  packet size is fixed to 1500 bytes;





Lochin & Dairaine          Expires May 5, 2006                  [Page 5]


Internet-Draft                    gTFRC                    November 2005


   o  we use a two colors token bucket marker with a bucket size of 10^4
      bytes defined in RFC 2697 [4];

   o  the queues size are 50 packets and RIO parameters are:
      (MIN_out,MAX_out,P_out, MIN_in,MAX_in,P_in) =
      (10,20,0.1,20,40,0.02);

   o  the bottleneck between the core and the egress router is
      1000Kbits/s;

   o  measurements are carried during 100 seconds.

   For each experiments, we evaluate the throughput at the server side
   and compute the instantaneous throughput and the average throughput
   for the experiment.  We resport the instantaneous throughput values
   at 20s, 50s and 100s.  Because some flow can cross one or several
   DiffServ domains and then, obtain a very large RTT difference, we
   compare flows with a high RTT difference (i.e., 600ms).

3.2.  Results

   The following table presents the comparative results between TFRC and
   gTFRC for an exactly provisioned network.

   +========+=======+========+=======+=======+=======+=======+
   |Protocol|  RTT  | Target | After | After | After |       |
   | #flow  |  (ms) | (Kb/s) |  20s  |  50s  |  100s |Average|
   +========+=======+========+=======+=======+=======+=======+
   | TFRC#1 | 640ms |  800   |  376  |  584  |  784  |  571  |
   | TFRC#2 |  40ms |  200   |  584  |  416  |  232  |  419  |
   +--------+-------+--------+-------+-------+-------+-------+
   |gTFRC#1 | 640ms |  800   |  376  |  784  |  800  |  722  |
   |gTFRC#2 |  40ms |  200   |  584  |  224  |  200  |  271  |
   +========+=======+========+=======+=======+=======+=======+

   Figure 2















Lochin & Dairaine          Expires May 5, 2006                  [Page 6]


Internet-Draft                    gTFRC                    November 2005


   The following table presents the comparative results between TFRC and
   gTFRC for an over-provisioned network with either same or different
   RTT values for the competing flows.

   +========+=======+========+=======+=======+=======+=======+
   |Protocol|  RTT  | Target | After | After | After |       |
   |Protocol|  (ms) | (Kb/s) |  20s  |  50s  |  100s |Average|
   +========+=======+========+=======+=======+=======+=======+
   | TFRC#1 | 250ms |  700   |  296  |  744  |  744  |  654  |
   | TFRC#2 | 250ms |  100   |  704  |  256  |  248  |  319  |
   +--------+-------+--------+-------+-------+-------+-------+
   |gTFRC#1 | 250ms |  700   |  744  |  800  |  696  |  727  |
   |gTFRC#2 | 250ms |  100   |  256  |  200  |  304  |  254  |
   +========+=======+========+=======+=======+=======+=======+
   | TFRC#1 | 640ms |  600   |  376  |  520  |  608  |  504  |
   | TFRC#2 |  40ms |  200   |  584  |  480  |  400  |  489  |
   +--------+-------+--------|-------+-------+-------+-------+
   |gTFRC#1 | 640ms |  600   |  376  |  600  |  600  |  554  |
   |gTFRC#2 |  40ms |  200   |  584  |  408  |  400  |  439  |
   +========+=======+========+=======+=======+=======+=======+

   Figure 3

   Extended results of this simulation campaign are available in [5]

3.3.  Analysis

   From these simulations, we see that gTFRC allows to reach a target
   rate more quickly than TFRC.  This is true whatever the RTT or the
   target rate of the flow.  The reason is obvious since at the first
   rate decrease evaluation of the algorithm, gTFRC returns a rate equal
   to the target rate.  If the evaluated rate is higher than the target
   rate, the classical TFRC algorithm is applied.  Concerning the
   DiffServ network behavior, the use of gTFRC raises the number of in-
   profile packets in the network and avoid the problem of the bandwidth
   sharing of the out-profile traffic.  For information purpose,
   concerning the Figure 2, between TFRC and gTFRC, the number of in-
   profile traffic raises from 73.7% to 90.16%.













Lochin & Dairaine          Expires May 5, 2006                  [Page 7]


Internet-Draft                    gTFRC                    November 2005


4.  Acknowledgements

   The author gratefully acknowledges the contributions of:

   o  Guillaume Jourjon, NICTA.

   o  EuQoS European Project members (http://www.euqos.org).


5.  References

   [1]  Heinanen, J., Weiss, W., Wroclawski, J., and J. Heinanen,
        "Assured Forwarding PHB Group", RFC 2597, STD 1, June 1999.

   [2]  Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
        Rate Control (TFRC): Protocol Specification", RFC 3448, STD 1,
        January 2003.

   [3]  Pieda, P., Ethridge, J., Baines, M., and F. Shallwani, "A
        Network Simulator Differentiated Services Implementation", Open
        IP , Nortel Networks, available at http://www.isi.edu/nsman/ns,
        July 2000.

   [4]  Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker",
        RFC 2697, STD 1, September 1999.

   [5]  Lochin, E., Dairaine, L., and G. Jourjon, "gTFRC: a QoS-aware
        congestion Control Algorithm", Research Report available at
        http://rp.lip6.fr/~lochin, October 2005.






















Lochin & Dairaine          Expires May 5, 2006                  [Page 8]


Internet-Draft                    gTFRC                    November 2005


Authors' Addresses

   Emmanuel Lochin
   National ICT Australia
   Australia Technology Park
   Eveleigh, NSW  1430
   Australia

   Phone: +61 8374 5541
   Email: Emmanuel.Lochin@nicta.com.au
   URI:   http://www.nicta.com.au


   Laurent Dairaine
   NICTA
   Australia Technology Park
   Eveleigh, NSW  1430
   Australia

   Phone: +61 8374 5206
   Email: Laurent.Dairaine@nicta.com.au
   URI:   http://www.nicta.com.au





























Lochin & Dairaine          Expires May 5, 2006                  [Page 9]


Internet-Draft                    gTFRC                    November 2005


Intellectual Property Statement

   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.

   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.

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Lochin & Dairaine          Expires May 5, 2006                 [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/