This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Is sender’s send buffer throttled by tcp?

0

I have a situation where the client is Ubuntu 12.04 and Mac OS X is the server. Now I took some dumps and saw that even when Linux is ready to receive more data, mac is not sending it. Note that the recv buffers of both Linux and Mac are enough to handle bigger amount of data.

In all scenarios, I am sure that mac always has more data to send then why is it not sending even when Bytes in flight is less than the receive window size of Linux.

Is there any tcp congestion control mechanism which can throttle the mac's send window? How do I change/optimize this value?

Main dump where this is visible is here. These two dumps here and here support this observation more.

asked 20 Nov '12, 08:51

Aditya%20Patawari's gravatar image

Aditya Patawari
31336
accept rate: 0%


One Answer:

2

Beside the fact that you already opened two questions regarding tcp send / recieve window, keeping people busy trying to help you and you did not accept any of those answers yet but now open the third question -> I will answer here too one more time, but I strongly suggest that you go back to reading about advanced TCP stack behaviour and related RFCs, since your questions are all about buffer management...

Back to your trace -> the sending stack DOES very well send as much data as allowed by recv. window. See example frame 3794, where bytes in flight is close to 200k.

However, since I suppose those traces again come from whatever sort of simulated latency environment, I can only guess what happens here.

Normally you don't have data coming in minor-MSS blocks when you have a high throughput transmission. Depending on the size of data blocks passed to TCP, TCP will segment data to fit MSS and send it. In your trace(s), there are tons of sub-MSS packets, which in that form are not sent by a normally behaving application, nor by the stack. You can sometimes observe patterns of minor-MSS packets now-and-then based on fixed read blocks e.g. of 32768 bytes per block or something, but this is not what a regular behaviour looks like.

So if you have a precise question and are willing to share information about the background of this tracefiles feel free to ask... and Yes under normal circumstances you should see the stack using recv. window at a certain point if bandwidth, delay and application data delivery is not limiting it in any way or if there is packet loss of course.

answered 20 Nov '12, 09:19

Landi's gravatar image

Landi
2.3k51442
accept rate: 28%

edited 20 Nov '12, 09:21

Hey, I apologize for not accepting any answers yet. Reason it that I just want to ensure that I accept the right answer. I have opened up a thread with UVNC a day before and I am following up with them and going through their code. I have read about tcp and these behaviors are weird to me that is why I am posting here.

I guess I have missed certain concepts and I am working hard to get things right. All the questions I asked are accompanied by 2-3 traces and I take a very hard look on the values before I ask anything.

I am really sorry if I offended you in any way.

(20 Nov '12, 23:01) Aditya Patawari