Issues for Mailing list of the Telecom Wireless 1.1 RTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7609: Issue/Telecom Wireless CORBA: Closing UTP Communication Session
Issue 7610: Issue/Telecom Wireless CORBA: Retransmissions in UTP
Issue 7611: Issue/Telecom Wireless CORBA: Sequence numbers of UTP messages

Issue 7609: Issue/Telecom Wireless CORBA: Closing UTP Communication Session (wireless-rtf)

There is no way in the current specification to gracefully close a communication session. This is not a problem, but may complicate recovery from communication failures.


Resolution: Add CloseRequest, CloseReply and CloseIndication chunks. CloseRequest/CloseReply pair of chunks allows negotiated closing of the UTP communication session. CloseIndition chunk allows a bridge to inform its peer bridge that it is going to close the UTP communication session.


Revised text:
Add the following three descriptions of UTP chunks at the end of subsection 7.4.1 'UDP Tunneling Protocol':
7. CloseRequest: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
8. CloseReply: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
9. CloseIndication: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.


Add the following three subsections at the end of section 7.4 'UDP Tunneling':


Close Request


The chunk Type is 0x07. The chunk does not have any other fields.


The chunk can be sent either by the Terminal Bridge or by the Access Bridge.


The bridge sends this chunk when it wants to close the communication session. After sending this chunk the bridge mwaits for the UTP message cointaining the CloseReply chunk. The bridge sending the CloseRequest chunk MUST process and acknowledge all UTP messages until receiving the CloseReply chunk.


When a bridge receives the CloseRequest chunk, it SHOULD immediately retransmit all unacknowledged UTP messages as well as all remaining GTP messages before sending the CloseReply chunk.


CloseReply


The chunk Type is 0x08. The chunk does not have any other fields.


The chunk can be sent either by the Terminal Bridge or by the Access Bridge in response to the CloseRequest chunk.


The bridge receiving the CloseRequest chunk SHOULD NOT send the CloseReply chunk before all other UTP messages have been acknowledgeged. After sending the CloseReply chunk, the bridge SHOULD wait for the acknowledgement before releasing all data structures associated with the UTP communication session.


The bridge receiving the CloseReply chunk SHOULD acknowledge the UTP message containing the CloseReply chunk by a UTP message having sequence number 0x0000. After sending this reply the bridge can release all data structures associated to the UTP communication session.


If a bridge receives CloseReply chunk, but it has not send the CloseRequest chunk, the bridge SHOULD send the CloseIndication chunk. See section 7.4.n 'CloseIndication'.


CloseIndication


The chunk Type is 0x09. The chunk does not have any other fields.


The chunk can be sent either by the Terminal Bridge or by the Access Bridge.


The bridge send this chunk to inform the peer bridge that it will close the communication session. The bridge MAY wait for the acknowledgement of the UTP message containing the CloseIndication chunk. In this case the bridge SHOULD discard all arriving UTP messages and response by retransmitting the UTP message containing the CloseIndication chunk. However, the bridge does not need to wait for the acknowledgement of the UTP message containing the CloseIndication chunk. It can immediately, after sending the CloseIndication chunk, release all data structures related to this communication session and stop accepting messages to the UDP port.


When the peer bridge receives the CloseIndication chunk, it SHOULD immediately acknowledge that UTP message and stop using the UDP end-point of the peer bridge. After sending the acknowledgement, the bridge SHOULD release all data structures related to the UTP communication session.

see below

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.

Usage of sequence numbers in UDP Tunneling Protocol messages in section 7.4 needs refinements.
We have found the following two problems:
1) If the first sequence number is arbitrary, then the receiver must examine the playload before it can detect whether or not the beginning of the message sequence is received.
2) If UTP messages containing only Acknowledge chunck are acknowledged, then we will have an infinite loop of ackning acks.


Resolution:
1) Start sequence numbers always from 0x0001.
2) Reserve sequence number 0x0000 for UTP messages that are not to be acknowledged (messages that only contain Acknowledge and/or Pause chunk).


Received text:
Add a new subsection 'Sequence Numberging' after the subsection 7.4.1 'UDP Tunneling Protocol':


Each communication session must start sequence numbering from 0x0001. In other words the UTP message containing the InitialAccessRequest chunk (or its first fragment) and the associated reply containing the InitialAccessReply chunk (or its first fragment) MUST have UTP Sequence Number 0x0001.


The sequence number counting follows the usual modulo arithmetic with the exception that the sequence number 0x0001 follows the sequence number 0xFFFF.


The UTP Sequence Number 0x0000 is reserved for UTP messages that only contain the Acknowledge chunk and/or the Pause chunk. These messages MUST NOT be acknowledged.


Add the following note at the end of subsections 7.4.3 'InitialAccessRequest' and 7.4.4 'InitialAccessReply':


Note: UTP message containing this chunk (or its first fragment) MUST have sequence number 0x0001.


Add the following two notes at the end of subsection 7.4.5 'Pause':


Note 1: If the UTP message contains only the Pause chunk (with or without the Acknowledge chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.


Note 2: After sending the Pause chunk, the sender SHOULD reply to each arriving message by a UTP message containing the Pause chunk. The UTP message MAY also contain ACknowledge and/or GTPData chunks.


Add the following note at the end of subsection 7.4.7 'Acknowledge':


Note: If the UTP message contains only the Acknowledge chunk (with or without the Pause chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.