What is the reason for checking mss with 1<<rcv_wscale?
include/net/tcp.h:
static inline void tcp_select_initial_window(int __space, __u32 mss,
__u32 *rcv_wnd,
__u32 *window_clamp,
int wscale_ok,
__u8 *rcv_wscale)
{
.....
/* Set initial window to value enough for senders,
* following RFC1414. Senders, not following this RFC,
* will be satisfied with 2.
*/
if (mss > (1<<*rcv_wscale)) {
int init_cwnd = 4;
if (mss > 1460*3)
init_cwnd = 2;
else if (mss > 1460)
init_cwnd = 3;
if (*rcv_wnd > init_cwnd*mss)
*rcv_wnd = init_cwnd*mss;
}
......
}
---------
Perhaps the motivation was checking for
if (mss > rcv_wnd * (1<<*rcv_wscale)) {
Thanks,
Prasanna.
On Wed, 27 Oct 2004 22:14:33 -0700
"Meda, Prasanna" <[email protected]> wrote:
>
> What is the reason for checking mss with 1<<rcv_wscale?
> include/net/tcp.h:
Because the advertised window field is 16-bits. It is
interpreted as "value << rcv_wscale"
> From: David S. Miller [mailto:[email protected]]
> Sent: Wednesday, October 27, 2004 10:21 PM
> To: Meda, Prasanna
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: rcv_wnd = init_cwnd*mss
>
>
> On Wed, 27 Oct 2004 22:14:33 -0700
> "Meda, Prasanna" <[email protected]> wrote:
>
> >
> > What is the reason for checking mss with 1<<rcv_wscale?
> > include/net/tcp.h:
> Because the advertised window field is 16-bits. It is
> interpreted as "value << rcv_wscale"
Thanks, still it is unclear to me why are we
downsizing the advertised window(rcv_wnd) to cwnd?
To defeat disobeying sender, or something like below?
Suppose when wscale is zero, it is now checking mss > 1,
and perhaps the intention was to check mss > rcv_wnd,
where mss is greater than advertised, and we still
want to advertise window to spwan 2 to 4 cwnd packets.
And also in the following line,
if (*rcv_wscale && sysctl_tcp_app_win && space>=mss &&
space - max((space>>sysctl_tcp_app_win), mss>>*rcv_wscale) <
65536/2)
space is actual_space>>rcv_wscale, mss is actual value.
Why are we checking space>=mss, which are in different
scales? The second line is doing max on space and mss
on same scales, and looks right.
Thanks,
Prasanna.
"David S. Miller" wrote:
> On Wed, 27 Oct 2004 23:15:48 -0700
> "Meda, Prasanna" <[email protected]> wrote:
>
> > Thanks, still it is unclear to me why are we
> > downsizing the advertised window(rcv_wnd) to cwnd?
> > To defeat disobeying sender, or something like below?
>
> There is never any reason to advertise a receive window
> larger than the initial congestion window of the sender
> could ever be.
>
> Setting it properly like this also makes sure that we do
> receive window update events at just the right place as
> the sender starts sending us the initial data frames.
That makes sense!
But are we coping with cwnd increase on sender?
Looks rcv rwnd s updated by only 1 pkt at time.
Thanks,
Prasanna.
On Wed, 27 Oct 2004 23:15:48 -0700
"Meda, Prasanna" <[email protected]> wrote:
> Thanks, still it is unclear to me why are we
> downsizing the advertised window(rcv_wnd) to cwnd?
> To defeat disobeying sender, or something like below?
There is never any reason to advertise a receive window
larger than the initial congestion window of the sender
could ever be.
Setting it properly like this also makes sure that we do
receive window update events at just the right place as
the sender starts sending us the initial data frames.
> And also in the following line,
> if (*rcv_wscale && sysctl_tcp_app_win && space>=mss &&
> space - max((space>>sysctl_tcp_app_win), mss>>*rcv_wscale) <
> 65536/2)
>
> space is actual_space>>rcv_wscale, mss is actual value.
> Why are we checking space>=mss, which are in different
> scales? The second line is doing max on space and mss
> on same scales, and looks right.
Yep, that space>=mss test looks super buggy for the *rcv_wscale
not zero case.
Good thing we don't have this buggy code in 2.6.x any more.
It's only present in 2.4.x