Hi Guys,

I am Gaurav and as part of my thesis work, I am building a CDMA System
simulator in OPNET 6.0. I am not a TCP-expert and I think I have come
across a TCP problem. My simulator consists of 3 main modules namely:
Mobile, Server, BTS. The Mobile requests a packet to download of size X
bytes, and the Server sends the X bytes in MTU 576 bytes size TCP
packets encapsulated in IP packets to the BTS, and the BTS sends it
over the air (wireless channel) to the Mobile. I am also simulating bit
errors due to fading, RLP packet errors etc. I have now run into an
interesting problem. Lets say that the maximum packet download rate for
the Mobile from the BTS is B bits/second, and Mobile downloads the
packet in an average of P seconds. Now, when I increase the maximum
packet download rate for the Mobile from the BTS (over the air) to 2*B
bits/second, I see that the Mobile's packet download time increases
beyond P seconds! That is, the Mobile takes longer to download the
packet. How can that be when there is more bandwidth on the access side
i.e. faster download over the air?

I think this is a TCP problem, and I am confident about the code that I
have written for the Access side. For the TCP algorithm, I am using
OPNET's TCP module, and have set the following parameters:

- Receive buffer (bytes): 65536
- Receive buffer usage threshold: 0.0
- Delayed ACK: Segment/Clock based
- Maximum ACK delay: 0.2 secs
- Max ACK segments: 2
- Slow start initial count: 1
- Fast retransmit: Disabled (I just needed a simple slow start +
congestion control TCP)
- Fast recovery: Disabled
- Window scaling: Disabled
- SACK: Disabled
- ECN capability: Disabled
- Nagle algorithm: Enabled
- Karn's algorithm: Enabled
- Initial RTO: 1 secs
- Minimum RTO: 0.5sec
- Max RTO: 64 sec
- RTT gain: 0.125
- Deviation gain: 0.25
- RTT deviation co-efficient: 4.0
- Timer granularity: 0.5 sec
- Persistence timeout: 1 sec

Can one of you TCP-experts please throw some light on what you think
may be happening?

One point to mention is that when I simulate multiple Mobiles, then the
BTS has a Scheduler which schedules the packet transmissions to the
Mobiles. Can this phenomenon be explained by the fact that, since we
have higher bandwidth at the access side, there are large bandwidth
oscillations and hence the TCP algorithm is backing off??

Another observation is that when I use MTU 1500, then this problem goes
away i.e. faster access download rate leads to overall shorter packet
download times for the mobiles (packet download time = time to download
packet from Server to Mobile).

Thanks in advance.

Gaurav (gaurav.hem@gmail.com).

You mention bit errors.

Some questions:

1. Which layers detects the bit errors ?

2. What does the layer do when it detects the bit errors ?

For example if the layer below tcp/ip detects the bit errors and cannot
recover and throws away the packet then TCP will interpret this lost packet
as congestion and TCP will start to slow things down in an attempt to solve
the congestion, ofcourse there is no real congestion just corruption,
slowing things down won't against corruption, so TCP will slow down
even more and more and more etc, at least that's the theory

I am not sure what TCP does when it itself detects an error... it would be
smart of TCP if it would not interpret this as congestion...

Bye,
Skybuck.

> Another observation is that when I use MTU 1500, then this problem goes
> away i.e. faster access download rate leads to overall shorter packet
> download times for the mobiles (packet download time = time to download
> packet from Server to Mobile).

RLP Packet retransmissions might be delaying the delivery of IP packets
when the RLP packet size is close to the TCP segment size. This might
be resulting in TCP timing out and resorting to retransmissions. When
you increase the TCP segment size, loss of an RLP packet towards the
beginning for the TCP segment might get hidden as RLP is able to
retransmit the lost packet before the reassembly of the complete TCP
segment has been completed.

Note that TCP will always treat a lost packet as a sign of congestion
and will reduce the window size, hence reducing the throughput.

--
VisualEther 1.0 - http://www.EventHelix.com/VisualEther
Generate sequence diagrams from Wireshark (Ethereal) output