TCP window size issues

Carl Mascott cmascott at att.net
Sat Oct 18 11:40:28 PDT 2003


> Andre Oppermann wrote:
> Carl Mascott wrote:
> > 
> > Here's a case that your logic does not handle correctly.
> > 
> > 1. Kernel default buffer size = 32 KB
> > 
> > 2. Routing table buffer size = 48 KB
> > 
> > 3. Application sets buffer size to 32 KB
> > 
> > 4. tcp_mss() selects 48 KB buffer size, giving the routing
> >    table precedence over the application.
>
> Tough luck... can't have everything.

I can have everything, I do have everything, and I'm willing
to share.  You are free to choose whether you want a simple
solution that works correctly in most cases or a slightly
more complex solution that works correctly in all cases.
Keep in mind that you are choosing for the entire community
of FreeBSD users, not just for yourself.
>
> > I found it necessary to add a new flag with meaning
> > "the application set my size" to struct sockbuf.
>
> I think you are overdoing this thing a little bit. Sendpipe and
> recvpipe can only be set by root with the route command. There
> is nothing changing that automagically in the kernel.
>
> Actually in my tcp_hostcache patch we still carry sendpipe and
> recvpipe even though there ain't no way to change it anymore
> (route has no longer access to it). It comes handy when we get
> auto-sizing socket buffers... (hint hint!)
>
> I don't think there are many people setting the pipesize at all.

Are you actually going to make NOPs out of the RTV_[RS]PIPE
bits in the rtm_inits field of struct rt_msghdr?  Unless you
are, any privileged application, not just 'route', will still
be able to set pipe sizes.  One such application is user ppp.
I _need_ this capability in user ppp, BTW, to prevent recv
queue overflow with a 5 KB/s PPP link while maintaining a
large default recv window on my other routes.

With autotuning of pipe sizes I think the PR 11966 patch is
going to have to be backed out: autotuning will sometimes
want to shrink the pipes.
>
> > I'll e-mail you a copy of my document.  Note that I have
> > backed out the patch from PR 11966.  You may not want to
> > do this.  It depends upon the correct answer to Issue #3
> > (shrinking the receive window) in my original posting.
>
> Got it. Still have to read it.
>
> > NOTE: AFAIK, 4.4BSD through FreeBSD 4.6-R seem to have done
> > alright without the PR 11966 patch, but if someone knows
> > different, please speak up.
>
> -- 
> Andre
>
>
> > Andre Oppermann wrote:
> > >
> > > The patch in PR11966 has already been applied. It does not fix it.
> > > I've fixed it by redoing this check in tcp_input.c::tcp_mss():
> > >
> > >  if ((bufsize = rt->rt_rmx.rmx_sendpipe) == 0)
> > >       bufsize = so->sn_snd.sb_hiwat;
> > >
> > > to:
> > >
> > >  if ((so->so_snd.sb_hiwat == tcp_sendspace) && rt->rt_rmx.rmx_sendpipe)
> > >       bufsize = rt->rt_rmx.rmx_sendpipe;
> > >  else
> > >       bufsize = so->so_snd.sb_hiwat;
> > >
> > >
> > > The theory goes that with default buffers so_snd.sb_hiwat and
> > > tcp_sendspace have the same size. If that is actually the case,
> > > we use whatever we've got from the metrics. If not, the user
> > > did some changes and we take that and ignore the metrics value.
> > > This is not yet tested in reality... just theoretical ;-)
> > >
> > > Anyway, I'm interested in your solutions as well.
> > >
> > > Carl Mascott wrote:
> > > >
> > > > Actually I have just fixed it in my copy of 4.8-R.  I have a document
> > > > that describes the problem and my solution.  I could send you that
> > > > and/or a set of patches.  You might want to sketch out your own
> > > > solution before you look at mine, though.  Also, I'm not done
> > > > testing mine yet.
> > > > > Carl Mascott wrote:
> > > > > >
> > > > > > 2. The 4.4BSD TCP implementation has never had the correct precedence
> > > > > >    rules for setting window sizes.  App-set values should take
> > > > > >    precedence over all others.  Routing table values should take
> > > > > >    precedence over kernel default values.  The fix for PR 11966
> > > > > >    alters the behavior but still doesn't implement these precedence
> > > > > >    rules.
> > > > >
> > > > > I'll fix this in my tcp_hostcache patch currently under review by
> > > > > Sam Leffler and Ruslan Ermilov (however that is for -CURRENT).
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>


More information about the freebsd-net mailing list