* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-04-09 10:56 Paolo Abeni
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Abeni @ 2020-04-09 10:56 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
[me is still somewhat alive]
On Sun, 2020-03-29 at 21:02 -0700, Mat Martineau wrote:
> On Fri, 27 Mar 2020, Paolo Abeni wrote:
>
> > On Thu, 2020-03-26 at 16:45 -0700, Mat Martineau wrote:
> > > To avoid confusion with 'ip address', what about using "ip mptcp
> > > adv-address" (or "advertise-addr"?) to clarify that these are addresses to
> > > be advertised, rather than something that creates new addresses?
> >
> > ok to rename, but the addresses specified here could be used for
> > advertise but also as source address for additional flows, so we would
> > need something more generic (and nothing come to my mind beyond
> > 'address').
>
> Good point. Would something like "default-addr" be generic for that
> purpose while still getting the point across that we expect these IP
> addresses to exist already, and are telling MPTCP to use them for any
> connection?
I'm wondering if something quite different, alike 'endpoint' would fit
better ?!? in (distant) future we could add even port numbers to
announced address.
Cheers,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-04-09 13:22 Davide Caratti
0 siblings, 0 replies; 6+ messages in thread
From: Davide Caratti @ 2020-04-09 13:22 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
On Thu, 2020-04-09 at 12:56 +0200, Paolo Abeni wrote:
> I'm wondering if something quite different, alike 'endpoint' would fit
> better ?!? in
the advantage of using an acronym is: you don't need to know what it
means, just spell it correctly :)
what about
# ip mptcp advertise-ma
where ma can be "multihomed (host) address", like mentioned in RFC 8684 §
2.3 ?
--
davide
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-03-30 4:02 Mat Martineau
0 siblings, 0 replies; 6+ messages in thread
From: Mat Martineau @ 2020-03-30 4:02 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]
On Fri, 27 Mar 2020, Paolo Abeni wrote:
> On Thu, 2020-03-26 at 16:45 -0700, Mat Martineau wrote:
>> On Thu, 26 Mar 2020, Paolo Abeni wrote:
>>
>>> Implement basic commands to:
>>> - manipulate MPTCP local addresses list
>>> - manipulate MPTCP connection limits
>>>
>>> Examples:
>>> 1. Allows multiple subflows per MPTCP connection
>>> $ ip mptcp limits subflows 2
>>>
>>> 2. Accept ADD_ADDR announcement from the peer (server):
>>> $ ip mptcp limits add_addr_accepted 2
>>>
>>> 3. Add a ipv4 address to be annunced for backup subflows:
>>> $ip mptcp address add 10.99.1.2 signal backup
>>>
>>> 4. Add an ipv6 address used as source for additional subflows:
>>> $ip mptcp address add 2001::2 subflow
>>>
>>> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
>>> ---
>>> diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c
>>> new file mode 100644
>>> index 00000000..1ff66a7b
>>> --- /dev/null
>>> +++ b/ip/ipmptcp.c
>>> @@ -0,0 +1,446 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +#include <stdio.h>
>>> +#include <string.h>
>>> +#include <rt_names.h>
>>> +#include <errno.h>
>>> +
>>> +#include <linux/genetlink.h>
>>> +#include <linux/mptcp.h>
>>> +
>>> +#include "utils.h"
>>> +#include "ip_common.h"
>>> +#include "libgenl.h"
>>> +#include "json_print.h"
>>> +
>>> +static void usage(void)
>>> +{
>>> + fprintf(stderr,
>>> + "Usage: ip mptcp address add <address> [dev <name>] [id <id>] [signal] [subflow] [backup]\n"
>>> + " ip mptcp address del id <id>\n"
>>> + " ip mptcp address list\n"
>>> + " ip mptcp address get id <id>\n"
>>> + " ip mptcp address flush\n"
>>> + " ip mptcp limits [subflows <nr>] [add_addr_accepted <nr>]\n");
>>> +
>>> + exit(-1);
>>> +}
>>> +
>>
>> Looking at the documentation for 'ip', there seem to be two command
>> styles:
>>
>> ip [ OPTIONS ] OBJECT { COMMAND } # for most commands
>>
>> ip xfrm XFRM-OBJECT { COMMAND } # for xfrm
>>
>>
>> and the above seems to fit the 'xfrm' style.
>>
>>
>> To avoid confusion with 'ip address', what about using "ip mptcp
>> adv-address" (or "advertise-addr"?) to clarify that these are addresses to
>> be advertised, rather than something that creates new addresses?
>
> ok to rename, but the addresses specified here could be used for
> advertise but also as source address for additional flows, so we would
> need something more generic (and nothing come to my mind beyond
> 'address').
Good point. Would something like "default-addr" be generic for that
purpose while still getting the point across that we expect these IP
addresses to exist already, and are telling MPTCP to use them for any
connection?
>
>> For consistency with other commands, "ip mptcp address show id <id>" could
>> be a better fit than 'get'.
>
> Ok, than is probably better also rename 'list' into 'show', so we will
> have a single 'getter' command with optional filter, WDYT?
Fine with me.
--
Mat Martineau
Intel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-03-27 16:32 Paolo Abeni
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Abeni @ 2020-03-27 16:32 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On Thu, 2020-03-26 at 16:45 -0700, Mat Martineau wrote:
> On Thu, 26 Mar 2020, Paolo Abeni wrote:
>
> > Implement basic commands to:
> > - manipulate MPTCP local addresses list
> > - manipulate MPTCP connection limits
> >
> > Examples:
> > 1. Allows multiple subflows per MPTCP connection
> > $ ip mptcp limits subflows 2
> >
> > 2. Accept ADD_ADDR announcement from the peer (server):
> > $ ip mptcp limits add_addr_accepted 2
> >
> > 3. Add a ipv4 address to be annunced for backup subflows:
> > $ip mptcp address add 10.99.1.2 signal backup
> >
> > 4. Add an ipv6 address used as source for additional subflows:
> > $ip mptcp address add 2001::2 subflow
> >
> > Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
> > ---
> > diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c
> > new file mode 100644
> > index 00000000..1ff66a7b
> > --- /dev/null
> > +++ b/ip/ipmptcp.c
> > @@ -0,0 +1,446 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <stdio.h>
> > +#include <string.h>
> > +#include <rt_names.h>
> > +#include <errno.h>
> > +
> > +#include <linux/genetlink.h>
> > +#include <linux/mptcp.h>
> > +
> > +#include "utils.h"
> > +#include "ip_common.h"
> > +#include "libgenl.h"
> > +#include "json_print.h"
> > +
> > +static void usage(void)
> > +{
> > + fprintf(stderr,
> > + "Usage: ip mptcp address add <address> [dev <name>] [id <id>] [signal] [subflow] [backup]\n"
> > + " ip mptcp address del id <id>\n"
> > + " ip mptcp address list\n"
> > + " ip mptcp address get id <id>\n"
> > + " ip mptcp address flush\n"
> > + " ip mptcp limits [subflows <nr>] [add_addr_accepted <nr>]\n");
> > +
> > + exit(-1);
> > +}
> > +
>
> Looking at the documentation for 'ip', there seem to be two command
> styles:
>
> ip [ OPTIONS ] OBJECT { COMMAND } # for most commands
>
> ip xfrm XFRM-OBJECT { COMMAND } # for xfrm
>
>
> and the above seems to fit the 'xfrm' style.
>
>
> To avoid confusion with 'ip address', what about using "ip mptcp
> adv-address" (or "advertise-addr"?) to clarify that these are addresses to
> be advertised, rather than something that creates new addresses?
ok to rename, but the addresses specified here could be used for
advertise but also as source address for additional flows, so we would
need something more generic (and nothing come to my mind beyond
'address').
> For consistency with other commands, "ip mptcp address show id <id>" could
> be a better fit than 'get'.
Ok, than is probably better also rename 'list' into 'show', so we will
have a single 'getter' command with optional filter, WDYT?
> For the limit changes, how about:
>
> ip mptcp limit set [subflows <nr>] [add_addr_accepted <nr>]
>
> ip mptcp limit get
> or
> ip mptcp limit show
Ok, I'll use 'show'
>
>
> Do you think the 'ip mptcp' command will be extended in the future for
> managing per-connection settings? That probably still works with the above
> syntax, for example by adding [connection <token>] to 'ip mptcp address
> add'.
>
>
> --
> Mat Martineau
> Intel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-03-27 14:31 Matthieu Baerts
0 siblings, 0 replies; 6+ messages in thread
From: Matthieu Baerts @ 2020-03-27 14:31 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]
Hi Paolo, Mat,
On 27/03/2020 00:45, Mat Martineau wrote:
>
> On Thu, 26 Mar 2020, Paolo Abeni wrote:
>
>> Implement basic commands to:
>> - manipulate MPTCP local addresses list
>> - manipulate MPTCP connection limits
>>
>> Examples:
>> 1. Allows multiple subflows per MPTCP connection
>> $ ip mptcp limits subflows 2
>>
>> 2. Accept ADD_ADDR announcement from the peer (server):
>> $ ip mptcp limits add_addr_accepted 2
>>
>> 3. Add a ipv4 address to be annunced for backup subflows:
>> $ip mptcp address add 10.99.1.2 signal backup
>>
>> 4. Add an ipv6 address used as source for additional subflows:
>> $ip mptcp address add 2001::2 subflow
>>
>> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
>> ---
Thank you for the good work!
>
>> diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c
>> new file mode 100644
>> index 00000000..1ff66a7b
>> --- /dev/null
>> +++ b/ip/ipmptcp.c
>> @@ -0,0 +1,446 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <stdio.h>
>> +#include <string.h>
>> +#include <rt_names.h>
>> +#include <errno.h>
>> +
>> +#include <linux/genetlink.h>
>> +#include <linux/mptcp.h>
>> +
>> +#include "utils.h"
>> +#include "ip_common.h"
>> +#include "libgenl.h"
>> +#include "json_print.h"
>> +
>> +static void usage(void)
>> +{
>> + fprintf(stderr,
>> + "Usage: ip mptcp address add <address> [dev <name>] [id
>> <id>] [signal] [subflow] [backup]\n"
>> + " ip mptcp address del id <id>\n"
>> + " ip mptcp address list\n"
>> + " ip mptcp address get id <id>\n"
>> + " ip mptcp address flush\n"
>> + " ip mptcp limits [subflows <nr>] [add_addr_accepted
>> <nr>]\n");
>> +
>> + exit(-1);
>> +}
>> +
>
> Looking at the documentation for 'ip', there seem to be two command styles:
>
> ip [ OPTIONS ] OBJECT { COMMAND } # for most commands
>
> ip xfrm XFRM-OBJECT { COMMAND } # for xfrm
>
>
> and the above seems to fit the 'xfrm' style.
>
>
> To avoid confusion with 'ip address', what about using "ip mptcp
> adv-address" (or "advertise-addr"?) to clarify that these are addresses
> to be advertised, rather than something that creates new addresses?
+1
> For consistency with other commands, "ip mptcp address show id <id>"
> could be a better fit than 'get'.
+1
>
> For the limit changes, how about:
>
> ip mptcp limit set [subflows <nr>] [add_addr_accepted <nr>]
>
> ip mptcp limit get
> or
> ip mptcp limit show
+1
> Do you think the 'ip mptcp' command will be extended in the future for
> managing per-connection settings? That probably still works with the
> above syntax, for example by adding [connection <token>] to 'ip mptcp
> address add'.
Good idea. It will be possible to retrieve these tokens with "ss". It
can be useful for the debugging.
For the rest mptcpd will be needed to track the connections.
Cheers,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface.
@ 2020-03-26 23:45 Mat Martineau
0 siblings, 0 replies; 6+ messages in thread
From: Mat Martineau @ 2020-03-26 23:45 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]
On Thu, 26 Mar 2020, Paolo Abeni wrote:
> Implement basic commands to:
> - manipulate MPTCP local addresses list
> - manipulate MPTCP connection limits
>
> Examples:
> 1. Allows multiple subflows per MPTCP connection
> $ ip mptcp limits subflows 2
>
> 2. Accept ADD_ADDR announcement from the peer (server):
> $ ip mptcp limits add_addr_accepted 2
>
> 3. Add a ipv4 address to be annunced for backup subflows:
> $ip mptcp address add 10.99.1.2 signal backup
>
> 4. Add an ipv6 address used as source for additional subflows:
> $ip mptcp address add 2001::2 subflow
>
> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
> ---
> diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c
> new file mode 100644
> index 00000000..1ff66a7b
> --- /dev/null
> +++ b/ip/ipmptcp.c
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <stdio.h>
> +#include <string.h>
> +#include <rt_names.h>
> +#include <errno.h>
> +
> +#include <linux/genetlink.h>
> +#include <linux/mptcp.h>
> +
> +#include "utils.h"
> +#include "ip_common.h"
> +#include "libgenl.h"
> +#include "json_print.h"
> +
> +static void usage(void)
> +{
> + fprintf(stderr,
> + "Usage: ip mptcp address add <address> [dev <name>] [id <id>] [signal] [subflow] [backup]\n"
> + " ip mptcp address del id <id>\n"
> + " ip mptcp address list\n"
> + " ip mptcp address get id <id>\n"
> + " ip mptcp address flush\n"
> + " ip mptcp limits [subflows <nr>] [add_addr_accepted <nr>]\n");
> +
> + exit(-1);
> +}
> +
Looking at the documentation for 'ip', there seem to be two command
styles:
ip [ OPTIONS ] OBJECT { COMMAND } # for most commands
ip xfrm XFRM-OBJECT { COMMAND } # for xfrm
and the above seems to fit the 'xfrm' style.
To avoid confusion with 'ip address', what about using "ip mptcp
adv-address" (or "advertise-addr"?) to clarify that these are addresses to
be advertised, rather than something that creates new addresses?
For consistency with other commands, "ip mptcp address show id <id>" could
be a better fit than 'get'.
For the limit changes, how about:
ip mptcp limit set [subflows <nr>] [add_addr_accepted <nr>]
ip mptcp limit get
or
ip mptcp limit show
Do you think the 'ip mptcp' command will be extended in the future for
managing per-connection settings? That probably still works with the above
syntax, for example by adding [connection <token>] to 'ip mptcp address
add'.
--
Mat Martineau
Intel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-09 13:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-09 10:56 [MPTCP] Re: [RFC PATCH 2/2] add support for mptcp netlink interface Paolo Abeni
-- strict thread matches above, loose matches on Subject: below --
2020-04-09 13:22 Davide Caratti
2020-03-30 4:02 Mat Martineau
2020-03-27 16:32 Paolo Abeni
2020-03-27 14:31 Matthieu Baerts
2020-03-26 23:45 Mat Martineau
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.