cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
354
Views
0
Helpful
3
Replies

TCP Behaviour in WAN Usage

tariqmansoor
Level 1
Level 1

Hi Team,

This may be a stupid question but it seems to me due to TCP behavior.

If we have 1Mbps WAN Link ( 1Mbps Pipe, with any QoS) and i start a file transfer and get the dpeed of 500Kbps. With first Transfer running i start the second file transfer and get the totoal speed or WAN utlization of 900Kbps.

Question is that why the first file did not make the full usage of available bandwidth ?

i.e

When there is no QoS on the WAN links how the apps make use of the bandwidth.

Any Assistance grealy appriciated.

Cheers,

1 Accepted Solution

Accepted Solutions

"..are you indicating the Window Size in TCP negotiation ?"

Yes. Although you normally don't see this issue at 1 Mbps unless your end-to-end latency is very high. Also, some host stack's default receive window size is larger if LAN is running at gig (I have in mind Windows host pre-Vista) which tends to avoid this from happening.

The other common TCP issue that will cause thoughput to be lower than expected are packet loss conditions that keep driving the TCP session back to slow start. (It's unusual for you to see this with one flow vs. two, I believe, since multiple TCP flows often will "sync" their loses.)

Lastly, have you provided enough time for TCP to fully ramp up? Two flows will ramp up faster than one flow.

View solution in original post

3 Replies 3

Joseph W. Doherty
Hall of Fame
Hall of Fame

Common cause for what you describe is the TCP receiving host not providing a large enough receive window to accomodate the bandwidth delay product (BDP) for a single TCP session.

Thanks, but i could't quite understand ..are you indicating the Window Size in TCP negotiation ? LAN PC has 1Gbps Network Cards and Link is only 1Mbps. and that happens to file transfer from any PC in the LAN.

Can you please provide bit more details or elaborate this.

Cheers,

"..are you indicating the Window Size in TCP negotiation ?"

Yes. Although you normally don't see this issue at 1 Mbps unless your end-to-end latency is very high. Also, some host stack's default receive window size is larger if LAN is running at gig (I have in mind Windows host pre-Vista) which tends to avoid this from happening.

The other common TCP issue that will cause thoughput to be lower than expected are packet loss conditions that keep driving the TCP session back to slow start. (It's unusual for you to see this with one flow vs. two, I believe, since multiple TCP flows often will "sync" their loses.)

Lastly, have you provided enough time for TCP to fully ramp up? Two flows will ramp up faster than one flow.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: