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

Versions: 00

Network Working Group                                         G. Jourjon
Internet-Draft                                                 E. Lochin
Expires: April 21, 2007                           National ICT Australia
                                                                P. Senac
                                                        LAAS-CNRS/ENSICA
                                                        October 18, 2006


                   Guidelines for a sender-based TFRC
                draft-jourjon-tsvwg-sender-based-tfrc-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 April 21, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo introduces the specification of a TFRC sender-based
   protocol.  This protocol is based on TFRC [2] congestion control and
   SACK [1] mechanism.  It enlights TFRC processing for the receiver and
   provides a robust architecture against selfish receiver behavior.
   This protocol remains compliant to the common TFRC as defined in [2].




Jourjon, et al.          Expires April 21, 2007                 [Page 1]


Internet-Draft                Sender-based                  October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Sender-based TFRC  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Receiver side  . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Maintaining the SACK structure . . . . . . . . . . . .  5
       3.1.2.  Reception of a packet  . . . . . . . . . . . . . . . .  5
       3.1.3.  Period of the feedback notification  . . . . . . . . .  5
     3.2.  Sender side  . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  Sending a data packet and reception of a feedback
               packet . . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.2.  From Loss History to Loss Events . . . . . . . . . . .  6
     3.3.  Modification of the TFRC feedback messages . . . . . . . .  7
       3.3.1.  TFRC generic headers . . . . . . . . . . . . . . . . .  7
       3.3.2.  New header on the sender side  . . . . . . . . . . . .  8
       3.3.3.  New header on the receiver side  . . . . . . . . . . .  9
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





























Jourjon, et al.          Expires April 21, 2007                 [Page 2]


Internet-Draft                Sender-based                  October 2006


1.  Introduction

   This memo proposes to redesign the TFRC protocol from a receiver-
   based architecture to a sender-based architecture.  Sender-based TFRC
   is based on an composition between the TCP-Friendly rate control
   (TFRC) and the Selective ACKnowledgment (SACK) mechanisms.  This
   document specifies the composition of these two mechanisms and the
   TFRC's modifications.

   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 concept of selective acknowledgments (SACK) was originally
   introduced in [1] as an extension to the reliability mechanism of TCP
   to provide an optimised full reliable service.  The SACK concept is
   detailed in [1].  By sending selective acknowledgments, the receiver
   of data can inform the sender about all segments that have been
   successfully delivered.  So, the sender needs to retransmit only the
   lost segments.  Feedback messages are produced by the receiver in
   order to inform the sending side about the current state of the
   receiving buffer and operate to a flow control.  Moreover, SACK
   information can be used to retransmit lost datagram packets following
   the partial reliable requirements of the application.  If partial
   reliability is controlled by the receiver, SACK can also include the
   accepted losses to avoid retransmission of obsolete data.





















Jourjon, et al.          Expires April 21, 2007                 [Page 3]


Internet-Draft                Sender-based                  October 2006


2.  Motivation

   The recent standardized DCCP protocol [3] is perceived as an
   efficient mechanism to carry multimedia traffic.  DCCP can apply
   multiple congestion control mechanisms and identifies the TFRC
   congestion control as congestion control ID #3 (DCCP/CCID3).  TFRC
   reproduces the TCP window-based congestion control mechanism through
   an equation model of the TCP equivalent throughput.  Rate-based
   congestion controls give more flexibility to the applications.
   Indeed, as opposed to window-based congestion controls, applications
   can directly negotiate and infer the transmitted rate.  This
   communication is possible as the rate is a parameter existing at
   transport and application levels.

   In the opposite to the powerful streaming multimedia player which
   diffuses the multimedia content, mobile devices are resource-limited
   end systems and are submitted to heavy application layer processing.
   Therefore the lightning of recurrent communication processing is a
   critical issue for increasing performances and autonomy of mobiles
   end systems.  One of main cost of TFRC mechanism is the periodic
   computation of the RTT and the loss rate of the data stream
   associated to the related transport connection.  As proposed in RFC
   3448, one of the possible solution to overcome this problem is to
   compute the loss rate estimation on the receiver side.  It also
   evokes that this computation could also be done on the sender-side.

   In this memo, we specify the design of a sender-based implementation
   of the TFRC congestion control mechanism.  In this proposal, the
   reliable delivery of feedback packets sent by the receiver to the
   sender is enforced by using a SACK-oriented mechanism.  This scheme
   is known to be robust to lossy channels while not entailing thigh
   constraints and heavy and complex error control mechanisms.  This
   computation requires maintenance of a loss event history data
   structure.  Such a receiver based solution does not comply with the
   capacities and resource constraints (i.e. in terms of energy
   consumption and overall computational performance) of light mobile
   receivers (e.g.  PDAs, mobile phones) which are more and more
   pervasive.  We detail below the modification to TFRC.













Jourjon, et al.          Expires April 21, 2007                 [Page 4]


Internet-Draft                Sender-based                  October 2006


3.  Sender-based TFRC

3.1.  Receiver side

   The mechanism MUST follow the TFRC [2] and MUST implement the the
   following changes.

3.1.1.  Maintaining the SACK structure

   The SACK structure should be a vector of bit that represents the
   packet arrived or lost.  This vector is an hollow vector, and it is
   noted in the next algorithm as the Packet_Structure

3.1.2.  Reception of a packet

   At the reception of a data packet the receiver should perform the
   following procedure:

   ReceivePacket(){
       add packet to received Packet_Structure
   }
   CreateFeedback(){
       calculate measured receive rate;
       prepare and send feedback packet;
       restart feedback timer;
   }

3.1.3.  Period of the feedback notification

   As the receiver does not send a feedback packet when it detects a
   loss event, the feedback period of the feedback timer must be
   inferior to the one in the original TFRC feedback period.

3.2.  Sender side

   The mechanism MUST follow the TFRC [2] and MUST implement the the
   following changes.

3.2.1.  Sending a data packet and reception of a feedback packet

   In order to detect a loss event at the sender side, the server has to
   set up a structure that stores information about the time it sends
   the packet.  This structure is the same as the one the receiver uses
   to compute the packet loss rate, except that instead of keeping a
   trace of the arrival time of the packet this new structure stores the
   sending time of the packet.  Based on this new structure the sender
   is now able to detect the difference between the lost of a packet and
   a loss event.  Furthermore the introduction of such structure allows



Jourjon, et al.          Expires April 21, 2007                 [Page 5]


Internet-Draft                Sender-based                  October 2006


   the suppression of the TimeStamp field in both data and feedback
   headers.

   As it will be possible to activate the SACK reliability mechanism,
   this new structure allows the sender to differentiate a lost of a
   packet feedback from a loss event feedback.

3.2.2.  From Loss History to Loss Events

   When it receives a feedback message, it proceeds, in addition to the
   usual operations to the analysis of the vector of ACKs.  This
   analysis is performed as follow:

   for(int i = 0; i < vector.lenght; i++){
       if(vector[i] == 0)
           add packet to Loss History
           p = new value of packet loss rate
       else
           Loss History to Loss Events
       }
   compute average packet loss rate

   vector is the SACK vector sent by the receiver. vector.lenght is the
   lenght of the SACK vector. p, Loss History and loss event are defined
   in [2]

   In section 5.2 of RFC 3448, the authors explain how to build loss
   event from the loss history.  This operation needs:

   o  S_loss the sequence number of the packet lost;

   o  S_before the sequence number of the last packet to arrive such
      that Sbefore infto S_loss;

   o  S_after the sequence number of the first packet to arrive such
      that Safter infto S_loss;

   o  T_before the reception time of S_before;

   o  T_after the reception time of S_after.

   In the presented solution, the sender is not aware of T_before and
   T_after.  Nevertheless, the sender has to estimate the arrival time
   of S_loss.  In our proposal, we will build loss events not on the
   arrival times but on the sending times.  These sending times are
   corrected by a factor alpha:

   alpha = X_sent/X_recv.



Jourjon, et al.          Expires April 21, 2007                 [Page 6]


Internet-Draft                Sender-based                  October 2006


   The determination of the new event is accomplished in the same way as
   in the original TFRC except that the reference of time is no longer
   the arrival time but the sending corrected by the factor alpha.

3.3.  Modification of the TFRC feedback messages

3.3.1.  TFRC generic headers

   As there is no specific definition of the TFRC headers in [2], we
   give below a format proposal in order to illustrate the modifications
   requested by the composition of TFRC and SACK mechanisms.

3.3.1.1.  On the sender side

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |           Dest Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          seq number           |           TimeStamp           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         current RTT           |           lenght              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             DATA
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields represented in the previous figure are defined as follow:

   o  Source Port: the number of source port of the protocol

   o  Dest Port: the number of destination port of the protocol

   o  seq number: the sequence number of the datagram

   o  TimeStamp: the creation time of the datagram

   o  current RTT: the most recently updated Round Time Trip

3.3.1.2.  On the receiver side












Jourjon, et al.          Expires April 21, 2007                 [Page 7]


Internet-Draft                Sender-based                  October 2006


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |           Dest Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        last seq number        |         lastTimeStamp         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          nbSeq sync           |        packet loss rate       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields represented in the previous figure are defined as follow:

   o  Source Port: the number of source port of the protocol

   o  Dest Port: the number of destination port of the protocol

   o  last seq number: the last sequence number of the received datagram

   o  lastTimeStamp: the creation time of the received datagram

   o  packet loss rate: the computed packet loss rate

3.3.2.  New header on the sender side

   The header of the data packet sould be as described above:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |           Dest Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          seq number           |           lenght              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          current RTT          |           ADU number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          nbSeq sync           |           DATA
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields represented in the previous figure are defined as follow:

   o  Source Port: the number of source port of the protocol

   o  Dest Port: the number of destination port of the protocol

   o  seq number: the sequence number of the datagram

   o  lenght: the size of the data carried in the datagram




Jourjon, et al.          Expires April 21, 2007                 [Page 8]


Internet-Draft                Sender-based                  October 2006


   o  ADU number: the application data unit number (optional)

   o  current RTT: the most recently updated Round Time Trip

   o  nbSeq sync: the sequence to synchronize with in the SACK structure

3.3.3.  New header on the receiver side

   The header of the feedback packet sould be as described above:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |           Dest Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        last seq number        |           nbSeq sync          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            OffSet             |           lenghtSack          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SACK Vector
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields represented in the previous figure are defined as follow:

   o  Source Port: the number of source port of the protocol

   o  Dest Port: the number of destination port of the protocol

   o  last seq number: the last sequence number of the received datagram

   o  OffSet: the offset of the SACK vector

   o  lenghtSack: the lenght of the sack vector

   o  SACK vector: the SACK vector















Jourjon, et al.          Expires April 21, 2007                 [Page 9]


Internet-Draft                Sender-based                  October 2006


4.  Acknowledgements

   This research work has been conducted in the framework of the EuQoS
   European project (http://www.euqos.org).  The authors were supported
   by NICTA.














































Jourjon, et al.          Expires April 21, 2007                [Page 10]


Internet-Draft                Sender-based                  October 2006


5.  Security Considerations

   Because it is located on the flows servers only, the proposed sender-
   based approach is more robust to selfish receivers.  Indeed, the
   sender is no longer dependent on the accuracy and the integrity of
   the returned information.  This fact is underlined in [2].

6.  References

   [1]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
        Selective Acknowledgement Options", RFC 2018, STD 1,
        October 1996.

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

   [3]  Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
        Control Protocol (DCCP),", RFC 4340, STD 1, March 2006.
































Jourjon, et al.          Expires April 21, 2007                [Page 11]


Internet-Draft                Sender-based                  October 2006


Authors' Addresses

   Guillaume Jourjon
   National ICT Australia
   Australia Technology Park
   Eveleigh, NSW  1430
   Australia

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


   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/


   Patrick Senac
   LAAS-CNRS/ENSICA
   1, place Emile Blouin
   Toulouse  31056 Cedex 5
   France

   Email: senac@ensica.fr
   URI:   http://dmi.ensica.fr/



















Jourjon, et al.          Expires April 21, 2007                [Page 12]


Internet-Draft                Sender-based                  October 2006


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


Acknowledgment

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




Jourjon, et al.          Expires April 21, 2007                [Page 13]


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