Subject: Re: TCP over GPRS

From: [email-masked]
Date: Fri, 19 Jan 2001 14:14:15 -0500

Andrei,

We uncovered a similar problem in the operation of clients running Windows 98 on
our network.  There is a Microsoft article that explains there is a bug in the
Win 98 TCP/IP stack's re-transmit timer.  Microsoft also provides a patch which
corrects this problem.  We tested it and it seems to work.  For more information
on the problem, visit their web-site at
http://support.microsoft.com/support/kb/articles/Q236/9/26.ASP.

Rod Ragland
Hughes Network Systems

Andrei Gurtov <[email-masked]> on 01/18/2001 06:58:21 AM

                                                              

 To:      [email-masked]                                   
                                                              
 cc:      [email-masked],                         
          [email-masked], [email-masked],        
          [email-masked](bcc: Roderick Ragland/HNS)     

 Subject: TCP over GPRS                                       

Hello,

 We have made TCP throughput measurements in a public GPRS
(packet-switched extension of GSM) network in Finland and observed quite
poor (about 60% of line rate) results in majority of tests. Measurements
were done in stationary conditions and Windows environment (server WinNT
and client Win98) since most customers use it. Poor TCP performance was in
a way a surprise since there were a number of papers predicting good
results. After collection and analysis of tcpdump traces the reason was
found to be in spurious fast retransmits and timeouts. The same packets
were unnecessary retransmitted up to four times so the throughput problem
was understandable. However, the reason of spurious retransmissions was
not in competing link-level ARQ recovery and TCP end2end retransmissions,
but rather in TCP implementation faults. The problem is that fast
retransmit is not prevented for DUPACKs coming to exactly seq_high ('more
careful' version of bug fix, see sec. 5 of rfc2582).  Because of this and
jumpy RTO timer, after a single packet loss due to buffer overflow or a
link error, the TCP connection collapses in a series of spurious
retransmissions.

This TCP implementation problem is fairly common, for example FreeBSD 4.0
and Linux 2.2 have it. See Figure 30 and 31 of my thesis at
http://www.cs.Helsinki.FI/research/iwtcp/papers/
Implementing 'more careful' bug fix or using the Eifel algorithm would
solve this problem. But how to fix Windows TCP? Perhaps increasing buffer
sizes and persistence of error recovery in GPRS network can help to get
around faulty TCP.

Example of tcpdump of Win-TCP over GPRS (uplink) is available at:
http://www.cs.Helsinki.FI/u/gurtov/wintrace/
and tcpdump of similar problem of FreeBSD at:
http://www.cs.Helsinki.FI/u/gurtov/bsdtrace/

Our paper containing measurement results for HSCSD and GPRS was accepted
to the IEEE International Conference on Communications 2001.

Andrei

---

From: Andrei Gurtov <[email-masked]>
Date: Mon, 22 Jan 2001 09:51:12 +0200 (EET)

Rod,

 Thanks a lot, I'll try this patch. The same problem also exists for
downlink transfers from NT server (although not so severe) and there is
a link to NT fix from the page you provided.
http://support.microsoft.com/support/kb/articles/Q232/5/12.ASP
 However, I think that incorrect RTO is only a part of the problem, and 
subsequent multiple fast retransmits should be blocked anyway.

Andrei

Andrei