Interesting TCP problem concerning 3G/4G technologies - TCP-IP

This is a discussion on Interesting TCP problem concerning 3G/4G technologies - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Interesting TCP problem concerning 3G/4G technologies

  1. Interesting TCP problem concerning 3G/4G technologies

    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).


  2. Re: Interesting TCP problem concerning 3G/4G technologies

    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 help 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.



  3. Re: Interesting TCP problem concerning 3G/4G technologies

    > 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


+ Reply to Thread