Subject: [rohc] ROHC-TCP issue: U/B mode, mode transition, and MSN

From: "Qian Zhang" <[email-masked]>
Date: Tue, 30 Apr 2002 12:27:27 +0800

Dear ROHC-TCPers,
 
We are working on updating the ROHC-TCP draft according to what was discussed at the Minneapolis meeting. 
We would like to discuss the following issues in separate email thread.
1. U/B mode, mode transition, and MSN issues
2. Context replication/updating issue, especially in U-mode

In this email, we will only focus on the first issue.

Regards,

Qian & Hongbin

-------------Mode related Issue-------------------------------------------
1. U/B mode, mode transition, and MSN issues

In ROHC-TCP, the B mode and U mode is like the O mode and U mode in ROHC-RTP, respectively. The difference between B and U modes is very subtle. In B mode, the decompressor needs send back ACK to the compressor occasionally. In ACKs, we need a field or combination of several fields to uniquely identify the packet received or not. TO achieve it, the current ROHC-TCP draft use different packet formats for U and B modes and support MSN in B mode. As a result, the transition from B mode to U mode will need 4-way handshakes to synchronize the compressor and the decompressor.

Compared to the complexity introduced by 4-way handshakes, uniform packet format is more preferred. However, there comes the issue which fields can be served as a unique identifier for the packet. As we had discussed before, in RTP, each packet is uniquely identified by a SN (Sequence Number) field. However, unlike RTP, TCP don't have such a field. The SEQ or ACK field only can not identify a packet. For example, in a client/server scenario, the packets on the path from client to server only see ACK changed with SEQ unchanged. Even the combination of SEQ and ACK can not complete solve the problem. Consider the case, when a packet gets lost, the TCP receiver sends back duplicate ACK without data. The SEQ and ACK remain constant at least for 3~4 packets. Moreover, SEQ (or ACK) counts octets instead of packets and will require more space to store it even in a compressed format.

The following is our proposal that trying to solve this issue. 
Instead of using different packet formats in U and B modes, we introduce a more complex FEEDBACK format. Some TCP/IP fields are put into the FEEDBACK format to identify the packet that needs to be acknowledged. In this way, same format for data packet is supported in both B and U modes. MSN is not needed in the uncompressed or compressed data packet.
The FEEDBACK formats are different between IPv4 and IPv6 since IP-ID is only available in IPv4. For IPv4, we use IP-ID as the unique identifier of the packet. For IPv6, we use SEQ, ACK or SEQ+ACK as the identifier of the packet. 

The procedure of mode-transitions between U-mode and B-mode are a little different from the one in ROHC-RTP.

Transition from U-mode to B-mode

When there is feedback channel available, the decompressor may at any moment decide to initiate transition from U-mode to B-mode. Any feedback packet carrying a CRC can be used with the mode parameter set to B. The decompressor can then directly start working in B-mode. The compressor transits from U-mode to B-mode as soon as it receive any feedback packet that has the mode parameter set to B and that passes the CRC check. The transition procedure is described below:

U-mode to B-mode

           Compressor                       Decompressor
             ---------------------------------------------
               |        ACK(B)/NACK(B)     +-<-<-|     D_MODE = B
C_MODE = B     |       +-<-<-<-<-<-<-<-<-<-+     |
               |-<-<-<-+                         |

Transition from B-mode to U-mode

The decompressor can force a transition back to U-mode if it desires to do so. Any feedback packet carrying a CRC can be used with the mode parameter set to U. The decompressor can then directly start working in U-mode. The compressor transits from B-mode to U-mode:
1) as soon as it receive any feedback packet that has the mode parameter set to U and passes the CRC check, or 
2) for an enough long time period (TIMEOUT), it hasn't received any feedback with the mode parameter set to B. 
The detailed procedure is described below:

B-mode to U-mode

	  Compressor                       Decompressor
          ---------------------------------------------
	       |        ACK(U)/NACK(U)     +-<-<-|     D_MODE = U
C_MODE = U   |       +-<-<-<-<-<-<-<-<-<-+     |
             |-<-<-<-+                         |

The FEEDBACK format is listed as follows:

- IPv4
For IPv4, the feedback format is very similar to ROHC-RTP, we just replace the SN in ROHC-RTP with IP-ID. The format is listed as follows:

FEEDBACK-1

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|             IP-ID             |
+---+---+---+---+---+---+---+---+

FEEDBACK-2

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|AckType| Mode  |     IP-ID     |
+---+---+---+---+---+---+---+---+
|             IP-ID             |
+---+---+---+---+---+---+---+---+
/       Feedback options        /
+---+---+---+---+---+---+---+---+

- IPv6
For IPv6, we only use FEEDBACK-2, the format is as follows:

FEEDBACK-2

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|AckType| Mode  | 0 | 0 | S | A |
+---+---+---+---+---+---+---+---+
/              SEQ              / if S = 1
 ... ... ... ... ... ... ... ... 
/              ACK              / if A = 1
+---+---+---+---+---+---+---+---+
/       Feedback options        /
+---+---+---+---+---+---+---+---+

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc