Issue 7610: Issue/Telecom Wireless CORBA: Retransmissions in UTP (wireless-rtf) Source: Nokia (Dr. Kimmo Raatikainen, kimmo.raatikainen@nokia.com kimmo.raatikainen@cs.helsinki.fi kraatika@cs.helsinki.fi) Nature: Uncategorized Issue Severity: Summary: The section 7.4 'UDP Tunneling' does not say anything about retransmissions. This may lead to implementations that are either suboptimal in bandwidth consumption or incompatible. Resolution: Give recommendations about retransmission policy similar to TCP's NewReno-SACK. Revised text: Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol SHOULD be controled by a policy based on an estimate for the Round Trip Time (RTT) such as NewReno-SACK in TCP [RFC nnnn]. The Retransmission TimeOut (RTO) MUST be at least the estimated RTT. Add the following note at the end of subsection 7.4.6 'Resume': Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk. Resolution: Revised Text: 4.1 Resolution - 1 Give recommendations about retransmission policy similar to TCP's NewReno-SACK. 4.2 Revised text - 1 Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol SHOULD be controlled by a policy based on an estimate for the Round Trip Time (RTT) such as NewReno-SACK in TCP [RFC 2582]. The Retransmission TimeOut (RTO) MUST be at least the estimated RTT. Add the following note at the end of subsection 7.4.6 'Resume': Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk. 4.3 Resolution - 2 Require that the transmission policy must be compliant to IETF's recommendations for TCP. 4.4 Revised text - 2 Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol MUST be compliant to IETF's recommendations for TCP as specified in [RFC 2581, RFC 2883, RFC 2988, RFC 3042, RFC 3517, RFC 3782]. Add the following entries into the subsection 1.3 'References': [RFC 2581] TCP Congestion Control, IETF, RFC 2581, April 1999. [RFC 2883] An Extension to the Selective Acknowledgement (SACK) Option for TCP, IETF, RFC 2883, July 2000. [RFC 2988] Computing TCP's Retransmission Timer, IETF, RFC 2988, November 2000. [RFC 3042] Enhancing TCP's Loss Recovery Using Limited Transmit, IETF, RFC 3042, January 2001. [RFC 3517] A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP, IETF, RFC 3517, April 2003. [RFC 3782] The NewReno Modification to TCP's Fast Recovery Algorithm, IETF, RFC 3782, April 2004. Add the following note at the end of subsection 7.4.6 'Resume': Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk. 4.5 Simplified revised text - 3 Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol are controlled by selective acknowledgements by retransmission timers as in TCP with SACK option enabled. When the sender detects from the selective acknowledgements that the acknowledged sequence has holes, the missing messages are immediately retransmitted. A message is also retransmitted when its retransmission timer expires. The retransmission timer MUST be computed as specified for TCP in RFC 2988 [RFC 2988]. Add the following entry into the subsection 1.3 'References': [RFC 2988] Computing TCP's Retransmission Timer, IETF, RFC 2988, November 2000. Add the following note at the end of subsection 7.4.6 'Resume': Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk. Actions taken: August 2, 2004: received issue March 10, 2005: closed issue Discussion: End of Annotations:===== canned: Mon, 2 Aug 2004 14:14:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Subject: Issue/Telecom Wireless CORBA: Retransmissions in UTP Date: Mon, 2 Aug 2004 14:13:31 +0300 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue/Telecom Wireless CORBA: Retransmissions in UTP Thread-Index: AcR4gb68Au68bA1TTue+oczAhMdNpw== From: To: Cc: X-OriginalArrivalTime: 02 Aug 2004 11:13:31.0580 (UTC) FILETIME=[BE863FC0:01C47881] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i72BPllj031204 The section 7.4 'UDP Tunneling' does not say anything about retransmissions. This may lead to implementations that are either suboptimal in bandwidth consumption or incompatible. Resolution: Give recommendations about retransmission policy similar to TCP's NewReno-SACK. Revised text: Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol SHOULD be controled by a policy based on an estimate for the Round Trip Time (RTT) such as NewReno-SACK in TCP [RFC nnnn]. The Retransmission TimeOut (RTO) MUST be at least the estimated RTT. Add the following note at the end of subsection 7.4.6 'Resume': From: "Kimmo Raatikainen" To: Victor Giddings Cc: wireless-rtf@omg.org Subject: Re: Voting on issues 7609, 7610 and 7611 Date: Wed, 22 Sep 2004 21:33:53 +0300 Victor, I see your point but different retransmissions policies do not create interoperability problems. Instead, we may get unnecessary retransmissions. However, I am ready to require NewReno-SACK based RTT estimation. Are we ready to require NewReno-SACK based RTT estimation? In that case the resolution text could be: Retransmissions in UDP Tunneling Protocol MUST be as in NewReno-SACK [RFC 2582]. - Kimmo Victor Giddings writes: Objective Interface votes YES on issues 7609, and 7611 Objective Interface votes NO on issue 7610. I believe the proposed resolution is inadequate to ensure interoperability. In particular, it would be conformant for two different implementation to have two different policies that would be incompatible. One possible resolution would be require (rather than suggest) RTT estimation based on NewReno-SACK. A couple of typos in the reports: 1) Shouldn't the title of section 3.2 be "Revised Text"? 2) In section 4.2: "controlled" not "controled" 3) Also in section 4.2: NewReno-SACK is RFC 2582 At 09:46 AM 9/20/2004 +0300, Kimmo Raatikainen wrote: Dear all, in Telecom Wireless 1.1 RTF we got three issues, all of them related to UDP Tunneling Protocol. The issues were mailed on August 3 with resolution proposals. I have drafted our RTF report. Now we need to vote on the issues. In order to have the RFT report in Washington AB meeting, I need your votes by next Monday, September 27. - Kimmo +------------------------------------------------------------------------ -+ | Kimmo Raatikainen, Professor | | University of Helsinki, Department of Computer Science | | mail: P.O.Box 68; FIN-00014 UNIVERSITY OF HELSINKI; Finland | | street address: Gustaf Hallstromin katu 2b; Helsinki | | email: kimmo.raatikainen@cs.helsinki.fi | | web: http://www.cs.helsinki.fi/Kimmo.Raatikainen/ | | phone: +358 9 191 51375; mobile: +358 5048 36275; fax: +358 9 191 51120 | +------------------------------------------------------------------------ -+ Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 +-------------------------------------------------------------------------+ | Kimmo Raatikainen, Professor | | University of Helsinki, Department of Computer Science | | mail: P.O.Box 68; FIN-00014 UNIVERSITY OF HELSINKI; Finland | | street address: Gustaf Hallstromin katu 2b; Helsinki | | email: kimmo.raatikainen@cs.helsinki.fi | | web: http://www.cs.helsinki.fi/Kimmo.Raatikainen/ | | phone: +358 9 191 51375; mobile: +358 5048 36275; fax: +358 9 191 51120 | +-------------------------------------------------------------------------+ X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Sep 2004 18:14:18 -0400 To: "Kimmo Raatikainen" From: Victor Giddings Subject: Re: Voting on issues 7609, 7610 and 7611 Cc: wireless-rtf@omg.org At 09:33 PM 9/22/2004 +0300, Kimmo Raatikainen wrote: Victor, I see your point but different retransmissions policies do not create interoperability problems. Instead, we may get unnecessary retransmissions. However, I am ready to require NewReno-SACK based RTT estimation. Are we ready to require NewReno-SACK based RTT estimation? In that case the resolution text could be: Retransmissions in UDP Tunneling Protocol MUST be as in NewReno-SACK [RFC 2582]. - Kimmo I' willing to be argued out of this position. What do you think? Wouldn't grossly different expectations on retransmission periods effectively render two different implementations not-interoperable? Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 From: "Kimmo Raatikainen" To: Victor Giddings Cc: wireless-rtf@omg.org Subject: Re: Voting on issues 7609, 7610 and 7611 Date: Tue, 28 Sep 2004 08:23:33 +0300 Victor et al. We should try to come into resolution on the retransmission issue (Issue 7610) in a week so that we can publish our RTF report on October 11. ACTIONS: 1) Andreas and Sumeet, give your initial votes on issues 7609, 7610, and 7611 ASAP. 2) ALL, state your favorite to resolve issue 7610 of the three possible ways given below by Thursday, September 30. I see three possible ways in resolving issue 7610: 1) Accept my proposal that OIS opposes but Nokia, Univ. Helsinki, and Prism Tech favours. It is an improvement to the current situation when nothing is said. However, I agree to some extent with Victor's argument that if the two bridges implement different retransmission policy, there will be some problems. However, IHMO the problems are not interoperability problems but performance problems due to either delayed retranmissions or unnecessary retransmissions. In any case the receiving end needs to be prepared to handled duplicate messages. 2) Reformulate the retransmission "guidelines" New resolution proposal: The implemented retransmission policy MUST be compliant with the current IETF recommendations for TCP retransmissions. (If we go to this option I will provide list of relevant RFCs in Friday) 3) Table this issue (and forward it to the next RTF) - Kimmo Victor Giddings writes: At 09:33 PM 9/22/2004 +0300, Kimmo Raatikainen wrote: Victor, I see your point but different retransmissions policies do not create interoperability problems. Instead, we may get unnecessary retransmissions. However, I am ready to require NewReno-SACK based RTT estimation. Are we ready to require NewReno-SACK based RTT estimation? In that case the resolution text could be: Retransmissions in UDP Tunneling Protocol MUST be as in NewReno-SACK [RFC 2582]. - Kimmo I' willing to be argued out of this position. What do you think? Wouldn't grossly different expectations on retransmission periods effectively render two different implementations not-interoperable? Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 +-------------------------------------------------------------------------+ | Kimmo Raatikainen, Professor | | University of Helsinki, Department of Computer Science | | mail: P.O.Box 68; FIN-00014 UNIVERSITY OF HELSINKI; Finland | | street address: Gustaf Hallstromin katu 2b; Helsinki | | email: kimmo.raatikainen@cs.helsinki.fi | | web: http://www.cs.helsinki.fi/Kimmo.Raatikainen/ | | phone: +358 9 191 51375; mobile: +358 5048 36275; fax: +358 9 191 51120 | From: "Kimmo Raatikainen" To: wireless-rtf@omg.org Subject: Issye 4610 - Resolution proposal 2 Date: Mon, 11 Oct 2004 14:38:15 +0300 Could you vote still today on the following - Kimmo PS Attached is draft of RTF report in whixh we move 4610 to the next RTF Issue 4610 Resolution - 2 Require that the transmission policy must be compliant to IETF recommendations for TCP. Revised text - 2 Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation': Retransmissions in UDP Tunneling Protocol MUST be compliant to IETF recommendations for TCP as specified in [RFC 2581, RFC 2883, RFC 2988, RFC 3042, RFC 3517, RFC 3782]. Add the following entries into the subsection 1.3 References [RFC 2581] TCP Congestion Control, IETF, RFC 2581, April 1999. [RFC 2883] An Extension to the Selective Acknowledgement (SACK) Option for TCP, IETF, RFC 2883, July 2000. [RFC 2988] Computing TCP's Retransmission Timer, IETF, RFC 2988, November 2000. [RFC 3042] Enhancing TCP's Loss Recovery Using Limited Transmit, IETF, RFC 3042, January 2001. [RFC 3517] A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP, IETF, RFC 3517, April 2003. [RFC 3782] The NewReno Modification to TCP's Fast Recovery Algorithm, IETF, RFC 3782, April 2004. Add the following note at the end of subsection 7.4.6 'Resume': Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk. +-------------------------------------------------------------------------+ | Kimmo Raatikainen, Professor | | University of Helsinki, Department of Computer Science | | mail: P.O.Box 68; FIN-00014 UNIVERSITY OF HELSINKI; Finland | | street address: Gustaf Hallstromin katu 2b; Helsinki | | email: kimmo.raatikainen@cs.helsinki.fi | | web: http://www.cs.helsinki.fi/Kimmo.Raatikainen/ | | phone: +358 9 191 51375; mobile: +358 5048 36275; fax: +358 9 191 51120 | +-------------------------------------------------------------------------+ Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk.