Date: Sat, 18 Oct 2003 14:40:22 -0400 (EDT) From: Carl Mascott <cmascott@att.net> To: oppermann@pipeline.ch Cc: freebsd-net@freebsd.org Subject: Re: TCP window size issues Message-ID: <200310181840.h9IIeM3o000408@callisto.local> In-Reply-To: <3F908A85.339EC78A@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310181840.h9IIeM3o000408>