From: V Anil Kumar <anil at csir4pi.in>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
Date: Sun, 15 Dec 2019 19:50:27 +0530 [thread overview]
Message-ID: <fa91c3e72444.5df68e83@nic.in> (raw)
In-Reply-To: A534F828-E876-454F-B734-1B5AC32FB027@strayalpha.com
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
Hi Joe,
On 12/14/19 10:48 PM, Joe Touch <touch(a)strayalpha.com> wrote:
>
>
>
>
>
>
>
>
>
>
> >
> > On Dec 14, 2019, at 5:39 AM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> >
> >
> >
> >
> > >
> > > The implementation needs to enforce a strict priority of DSS over SACK and ADD_ADDR.
> > >
> >
> > TCP options have evolved over a period of time, and I do not think as such any document/guidelines exist on enforcing priority for one over the other, though it turns out be an interesting topic. Also, more TCP options could come up in future for implementing new features. So, it is likely that implementations would follow different strategy when it come to option priority.
> >
> >
>
>
>
> FYI, this has come up as an issue before.
>
>
>
>
> TCP options are individual and accepted in isolation. They are easily confirmed only during SYN exchange; anything after that requires a stateful, reliable transmission mechanism for coordination.
>
>
>
>
> There is no way to retrofit any ordering constraints, or prioritization. If you need that sort of feature, it needs to be built inside a single option as “sub options”.
>
>
>
>
>
>
Thank you for sharing this information.
I agree with this.
Anil
>
>
>
>
>
> Joe
>
>
>
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3415 bytes --]
next reply other threads:[~2019-12-15 14:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-15 14:20 V Anil Kumar [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-12-20 8:42 [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis Christoph Paasch
2019-12-18 5:07 V Anil Kumar
2019-12-15 17:05 Christoph Paasch
2019-12-15 11:05 Yoshifumi Nishida
2019-12-14 17:18 Joe Touch
2019-12-14 13:39 V Anil Kumar
2019-12-13 18:24 Christoph Paasch
2019-12-13 18:11 V Anil Kumar
2019-12-13 16:29 Christoph Paasch
2019-12-13 5:52 V Anil Kumar
2019-12-11 19:22 Christoph Paasch
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=fa91c3e72444.5df68e83@nic.in \
--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.