perfSONAR User Q&A and Other Discussion

["Garnizov, Ivan (RRZE)" <>]

Hi guys,

Here are my 50 cents in this interesting thread.
It is not necessary to see retransmits in cases where a congestion management 
is applied (as Brian referred to it "smaller buffer").
He pointed that this is a pattern for an intermediate device being 
overwhelmed. That alone suggests that on one side of the connection there is 
a router, which on a certain threshold starts sending flow control messages 
to the toolkit to slow down. This does not even mean the router is 
overwhelmed with traffic. It means the router sees the possibility of being 
congested and immediately sends control messages to one party to reduce the 
size of the window.

In this case there are no overruns on the interfaces. Of course a possible 
problem at the sender should be investigated first, if it is capable of 
transmiting at these speeds.

Regards,
Ivan


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Brian Candler
Sent: Montag, 20. Juni 2016 15:52
To: 
;
 Eschen, Brian
Cc: 

Subject: Re: Re: [perfsonar-user] TCP window size problems

On 20/06/2016 10:10, Brian Tierney wrote:
> That is a somewhat common pattern if there is a device in the path 
> with buffers that are too small.
>
> You can config perfsonar to use a smaller buffer using the GUI, or 
> editing the mesh config file.
>
By "smaller buffer" do you mean smaller TCP window size?

I note that in the reported stats there are no retransmissions reported (Retr 
= 0); so what's the mechanism by which an intervening device could reduce the 
throughput to the given value, without dropping packets?

I also see that the congestion window has ramped up to 21.8MB and stuck 
there. I don't know what the RTT is between those two endpoints, but let's 
say it's 70ms for sake of argument. That would imply a throughput of about 
2500Mbps I think. (1000/70 * 21.8 * 8)

Is it possible that the window size at the other end is set lower than 
expected? Perhaps if the OP captured the initial TCP SYN exchange it would 
make this clear (remembering to decode the TCP window scaling factor)

Also, the OP said that applying the -w option (without saying the value
used) could achieve a higher throughput. So it should be possible to compare 
the TCP SYN exchange, with and without the -w option, to see what's different.

Regards,

Brian Candler.