On Thu, Sep 12, 2019 at 1:59 AM Neal Cardwell <ncardw...@google.com> wrote: > > On Wed, Sep 11, 2019 at 6:32 PM Thomas Higdon <t...@fb.com> wrote: > > > > Neal Cardwell mentioned that rcv_wnd would be useful for helping > > diagnose whether a flow is receive-window-limited at a given instant. > > > > This serves the purpose of adding an additional __u32 to avoid the > > would-be hole caused by the addition of the tcpi_rcvi_ooopack field. > > > > Signed-off-by: Thomas Higdon <t...@fb.com> > > --- > > Thanks, Thomas. > > I know that when I mentioned this before I mentioned the idea of both > tp->snd_wnd (send-side receive window) and tp->rcv_wnd (receive-side > receive window) in tcp_info, and did not express a preference between > the two. Now that we are faced with a decision between the two, > personally I think it would be a little more useful to start with > tp->snd_wnd. :-) > > Two main reasons: > > (1) Usually when we're diagnosing TCP performance problems, we do so > from the sender, since the sender makes most of the > performance-critical decisions (cwnd, pacing, TSO size, TSQ, etc). > From the sender-side the thing that would be most useful is to see > tp->snd_wnd, the receive window that the receiver has advertised to > the sender.
I am under the impression, that particularly in the mobile space, that network behavior is often governed by rcv_wnd. At least, there's been so many papers on this that I'd tended to assume so. Given a desire to do both vars, is there a *third* u32 we could add to fill in the next hole? :) ecn marks? > > (2) From the receiver side, "ss" can already show a fair amount of > info about receive-side buffer/window limits, like: > info->tcpi_rcv_ssthresh, info->tcpi_rcv_space, > skmeminfo[SK_MEMINFO_RMEM_ALLOC], skmeminfo[SK_MEMINFO_RCVBUF]. Often > the rwin can be approximated by combining those. > > Hopefully Eric, Yuchung, and Soheil can weigh in on the question of > snd_wnd vs rcv_wnd. Or we can perhaps think of another field, and add > the tcpi_rcvi_ooopack, snd_wnd, rcv_wnd, and that final field, all > together. > > thanks, > neal -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740
