Why sender did not have more in-flight bytes to client?

bytes-in-flight

asked 2020-11-24 15:44:54 +0000

codec
1 ●1 ●1 ●2

updated 2020-11-24 15:51:39 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●973 ●227 https://www.wireshark.org

I use Bluecoat proxy for testing, and the configured proxy server has a 500Kbytes TCP window size. But I found the proxy sometimes just sent two packages to the client, then the client will send one ack.

Sometimes, the proxy will send 15 packages (21456 bytes in flight) to the client and then receive the client's ACK back.

Does anyone know how the proxy (sender) controls the in-flight bytes? is it possible to have more in-flight bytes to increase the throughput?

the client is windows 10 and connecting to server via bluecoat proxy. And the client and sender (bluecoat) are on LAN and RTT is less than 1 ms.

Thank you!

edit retag flag offensive close merge delete

Comments

Have you looked at the window size in the client ACKs?

Chuckc ( 2020-11-24 16:49:51 +0000 )edit

There may be several reasons why the TCP window size is not fully utilized. For example:

TCP slow start mechanism active.
TCP slow start was retriggered after some idle time.
The initial windows size depends on some configuration on the bluecoat
Data was send with PUSH flag set.
The application has simply no more data to send...
Low latency allows for small window size in use (ACK's come in fast).

Maybe using a (software) WAN emulator may help to get more realistic behaviour.

André ( 2020-11-24 21:45:31 +0000 )edit

for download (server -> bluecoat -> client). I captured in client system, the ACK to bluecoat largest Calculated window size is 1723648 to bluecoat. I found from bluecoat to client the in-flight bytes can up to ~200KB, but most in-flight is between 50KB - 20 KB from Bluecoat to client.

codec ( 2020-11-28 04:50:00 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-11-28 04:28:46 +0000

codec
1 ●1 ●1 ●2

Upload through the ProxySG could be slower compared to without ProxySG due to the smaller TCP Window Size. https://knowledge.broadcom.com/extern...

From the beginning, I have this problem in a real environment, and I tested the TCP window in the testing environment and can see the upload and download can improve after the TCP window size changed to large.

Then I implemented a change in a real environment. Sometimes the speed can improve, but sometimes it does not. I think it may cause by the whole environment has many factors to impact the throughput. But I want to prove the TCP window can improve the speed.

I also use speedtest.net to check the result, and it shows large TCP-window is fast than a smaller one. https://knowledge.broadcom.com/extern...

Is there any way to use the capture file's output that matched the Broadcom tech document's result?

edit flag offensive delete link

add a comment

answered 2020-11-25 08:43:50 +0000

hugo.vanderkooij
76 ●190 ●4

Actually I think this is more of a Broadcom (Broadcom bough Symantec, Symantec bought Blue Coat) support ticket issue.

I happen to know a good deal about the Blue Coat proxies and I would start with a list of things I would like to see from your proxy. But certain behaviour of an individual client still does not clarify things as wrong or even odd.

The proxy can't present data unless it got it at some time from an upstream webserver or it can provide it from cache. So I think it is rather hard to tell without exposing a great deal of information.

But the behaviour in itself is not wrong. And in this case it is the client that has the variation on when it sends an ACK. So that might tell you more about the client being not consistent. And that could just be a browser thing (I would not call it an issue).

So there is no simple answer as there is no fault and definitly not enough information to determine anything else.

edit flag offensive delete link

add a comment