Re: Clarification on behaviour of Iperf's -w option

[Lawrence Stewart <lstewart --at-- room52.net>]

Hi Marc,

Comments inline once again.


Marc Herbert wrote:
> Lawrence,
>
> Glad to see we achieved mutual understanding on the technical side.
>
>
> On Wed, 1 Aug 2007, Lawrence Stewart wrote:
>
> > Agreed. This would save quite a bit of confusion. Although dropping the
> > "window size" term completely is perhaps not quite the right way to
> > handle it. As you note below, the receive buffer size is related to the
> > TCP window. Perhaps changing the terminology to refer to "maximum
> > advertised window" would make it clearer.
>
> Also please note that, due to latency, the sender systematically sees 
> a smaller TCP window than the one published to him by the receiver at 
> the same time.
>
> That's really the big problem with the current documentation: it makes 
> the user believes she can set a complex and very dynamic protocol 
> value. Untrue. And we are not even speaking of congestion avoidance here.

Yup, absolutely. It does sound like it "fixes a value" for the duration 
of the test.

> But I'm fine with "maximum advertised".

Cool. I think this just adds a bit of context, as people not familiar 
with how the TCP/IP stack and sockets API interact might not connect (no 
pun intended!) the socket send/receive buffer sizes and their impact on 
TCP dynamics. Stating that the receive buffer places an upper bound on 
*our* maximum advertised window, and that the send buffer places bounds 
on the maximum advertised window we can service adds that extra bit of 
context I think.

> > I feel that having a switch behave differently when used in 2 different
> > contexts is very confusing. You could change the documentation to
> > explain the current behaviour, but that would involve describing 2
> > different behaviours depending on running in client or server mode, and
> > also makes it more difficult to implement an additional switch to
> > provide the fine grained control over either send or receive buffer 
> > sizes depending on whether you run in client or server mode.
>
> > You do make a fair point regarding the entrenched use of the "-w" switch
> > in its current form. Perhaps the "-w" switch could be left intact and a
> > pair of new switches added to specifically set the send/receive socket
> > buffer sizes. Use of these switches and the "-w" switch could be made
> > mutually exclusive so they don't step on eachother's toes. To me,
> > leaving the "-w" switch intact still feels a bit hacky... but I can see
> > why it would be useful.
>
>
> I'm less affirmative concerning user interface design but I believe in 
> backward compatibility. I agree that the "too clever" behaviour of the 
> current -w option is a bit confusing, but it seems to me it still can 
> be documented correctly. This can even be terse provided it stands 
> after the new options. Something like this:
>
>
>     -X1
>          Sets the receive buffer size / maximum TCP window size
>          [blabla].
>
>     -X2
>          Sets the send buffer size [blabla].
>
>     -w
>         "Magic" buffer size: sizes the receive buffer on the receiver,
>          and the send buffer on the sender.

I think this sounds like a good compromise :)

Leave -w behaviour as is, add 2 new options and document all 3 options 
appropriately.

> This does not solve the case of "-w" for bi-directional tests. IMHO 
> people performing bi-directional tests have already buried themselves 
> in deep complexity, so simplify the interface and documentation for 
> them should not be the priority :-> I would not bother and leave the 
> magic "-w" option "undefined" for bi-directional tests.

I think a simple cautionary note in the docs stating that "-w is only 
really useful in unidirectional tests. Use -X1 and -X2 to tune buffers 
for bidirectional tests" would cover this.

> In any case, you are actively working on this (unlike me), so your 
> word has de-facto more weight than mine.

I'm just trying to make sure the patch is of maximum benefit to Iperf 
with minimal side effects, so I really appreciate your feedback. I'll 
have a go at changing the patch to reflect our discussion and get back 
to the list when it's ready.

> Cheers,
>
> Marc.
>
>
> PS: after all this, I'd like to remind that iperf is a really great 
> tool. Else we would not even bother spending so much time arguing 
> about making it even better.

I of course second these sentiments!

Cheers,
Lawrence