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]