From: Florian Westphal <fw at strlen.de>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [PATCH mptcp-next] mptcp: keep track of receivers advertised window
Date: Wed, 26 Aug 2020 20:44:42 +0200 [thread overview]
Message-ID: <20200826184442.GA7319@breakpoint.cc> (raw)
In-Reply-To: alpine.OSX.2.23.453.2008251627090.25312@ticede-or-125.amr.corp.intel.com
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
Mat Martineau <mathew.j.martineau(a)linux.intel.com> wrote:
> On Sun, 23 Aug 2020, Florian Westphal wrote:
> It looks like this would ratchet up msk->snd_wnd based on the largest
> subflow snd_wnd seen in the life of the connection.
>
> Section 3.3.5 in the RFC says to "only update its local receive window
> values when the largest sequence number allowed (i.e., DATA_ACK + receive
> window) increases on the receipt of a DATA_ACK". So that would compare
> new_snd_una + ssk_snd_wnd and old_snd_una + sk_snd_wnd, and it would be
> possible to have mismatched values for msk->snd_wnd and msk->snd_una if
> there were concurrent reads or writes.
>
> What if this patch added msk->wnd_end instead of msk->snd_wnd? Then the msk
> window information used at transmit time would always be valid, and it
> doesn't really matter if the msk->snd_una update lags a little bit.
Sounds like a good plan, I will look into it. Thanks for reviewing!
next reply other threads:[~2020-08-26 18:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 18:44 Florian Westphal [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-08-26 0:10 [MPTCP] Re: [PATCH mptcp-next] mptcp: keep track of receivers advertised window Mat Martineau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200826184442.GA7319@breakpoint.cc \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.