Subject: Withdraw: The TCP Retransmit (RXT) Flag

From: Reiner Ludwig <[email-masked]>
Date: Thu, 13 Dec 2001 15:44:25 +0100

after lots of discussion with various people, mostly Mark Allman, I'm now 
convinced that the benefit of a TCP RXT flag does not justify allocating a 
bit in the Reserved Field of the TCP header.

Therefore, I herewith withdraw draft-ludwig-tsvwg-tcp-rxt-flag-03.txt.

For those interested, here is why ...

Most wide-area wireless networks (e.g., GSM, IS95, GPRS, WCDMA, CDMA2000) 
provide some form of reliability at the link layer. This includes ARQ 
schemes and (in some networks) also schemes to avoid packet losses in the 
event of cell handovers. This has proven to benefit TCP's performance for 
most or at least the "typical" wireless scenarios. But in some cases it may 
lead to spurious timeouts. This can become rather painful, depending on how 
fast a user moves from one radio coverage cell to the other, congestion 
from one cell to the other, radio coverage holes in that geographical area 
(mountains, buildings, tunnels, insufficient coverage provided by the 
wireless network provider, etc.), resource blocking due to higher priority 
traffic (e.g., voice calls or Short-Message-Services), etc., etc.

One of our bigger headaches here are the unnecessary go-back-N retransmits 
that inevitably occur after a spurious timeout. Those are often hard to 
avoid even with a conservative RTO like RFC 2988. Not only does the TCP 
sender break 'packet conservation' when it slow starts those go-back-N 
retransmits into the network, it also reduces throughput and wastes 
precious radio resources (spectrum & battery power). To avoid this, a 
retransmit-marker is required that can be used to eliminate TCP's 
retransmission ambiguity problem.

We already have such a retransmit-marker: the TCP Timestamps option 
[RFC1323]. However, because of the 12 bytes overhead that timestamps add to 
each packet, and the fact that timestamps effectively disable widely 
deployed RFC 1144 TCP/IP header compression, we looked for a more efficient 
solution: the proposed TCP RXT flag.

However, it turns out that timing every packet to update the RTT estimators 
is advantageous when running TCP across such networks. A path across such 
networks is typically bandwidth-dominated which means that the slightest 
"unsmoothness" in the transmission within such networks may greatly impact 
a packet's RTT. Thus, the RTT may vary quite a lot from one packet to the 
other. Timing every packet helps keeping closer track of the RTT and leads 
to a more conservative RTO since RTO-RFC2988 is quite sensitive to RTT 
variations. Studies have shown that timing every packet helps reducing the 
risk of a spurious timeout when running TCP across such networks.

Although, timestamps are not essential to time every packet, they are still 
one way of doing it. And since the Timestamps option seems to be widely 
deployed, it's likely that TCP's will simply use them for that purpose. If 
that was the case then this would make a TCP RXT flag pretty much redundant.

With respect to the overhead added by timestamps, we then simply have to 
wait for the ROHCer to provide us with an appropriate TCP/IP header 
compression scheme.

Bye, bye "TCP RXT flag" ;-(

In case, people (Lloyd?) want to comment, please, do so at 
[email-masked] instead of cross-posting to [email-masked].

///Reiner