Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982021B31FC for ; Wed, 4 Nov 2015 07:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYd9S6hBByYj for ; Wed, 4 Nov 2015 07:45:05 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 553291B31F5 for ; Wed, 4 Nov 2015 07:45:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id 2F99D3B7C04C; Wed, 4 Nov 2015 16:44:59 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zULwmkdTwKD2; Wed, 4 Nov 2015 16:44:57 +0100 (CET) Received: from w540.sistemnet.local (93-139-83-90.adsl.net.t-com.hr [93.139.83.90]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 96B1B3B7C047; Wed, 4 Nov 2015 16:44:57 +0100 (CET) To: Erik Kline References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> <5637306E.40006@fer.hr> <56376171.7060203@fer.hr> From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <563A27EC.70000@fer.hr> Date: Wed, 4 Nov 2015 16:44:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo" Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 15:45:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo Content-Type: multipart/alternative; boundary="------------040503090709050602040007" This is a multi-part message in MIME format. --------------040503090709050602040007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04.11.2015 13:01, Erik Kline wrote: > > > On 2 November 2015 at 22:13, Stjepan Gro=C5=A1 > wrote: > > > On 02.11.2015 13:18, Erik Kline wrote: >> >> On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 > > wrote: >> >> Hi Erik, >> >> Thank you for the draft. >> >> I have few comments/questions. >> >> First, what I'm reading from the draft is that each PvD aware >> application should have access to a single PvD at any single >> moment? If that is so, what about mpTCP and SCTP applications >> that are PvD aware? They should have access to multiple PvDs >> simultaneously for a fail over reasons. So, how this draft >> takes into account that use case? >> >> >> Not quite: they should be able to specify only one PvD per >> function call, per thread (for example). An app can have >> multiple sockets, each one using one PvD. An app can have >> something like a single unconnected datagram socket and call >> sendto() with a different PvD for each sendto() call. That kind >> of thing is more what I meant to write, but I guess was not very >> clear. (Clearly, I have a bunch of sockets-y things in my head >> but am trying to write things in a more general, >> non-sockets-dependent way.) >> >> The confusion may be arising in part from the resolution of which >> PvD to use for a given function call if no PvD is specified. In >> those cases, the system checks for "defaults" at increasingly >> general levels. So a process could set a process default PvD and >> avoid having to specify the PvD for each an every call, but still >> make individual socket calls or query DNS on a different PvD >> whenever it wants to. >> >> Does this make more sense? > > I was thinking on functions like sctp_bindx that explicitly expect > multiple IP addresses to be present at a point when the function > is called. mpTCP could be even bigger problem because, as I > understand it, Linux kernel autonomously decides which local IP > addresses to use. > > > Ah, thank you, that kind of call is an important consideration. I > believe I have a solution that will work: when determining the > intended PvD in the case of existing APIs that specify source > addresses (and/or maybe even interfaces) we should use PvDs that are > uniquely identified by this information. You mean like having some separate function which is called before sctp_bindx with the same arguments so that appropriate PvDs can be activated? We were thinking about some kind of a PvD activation function (e.g. pvd_attach_pvd(pvdid *id) and possibly also pvd_detach_pvd) so that application can attach any combination of PvDs it wants to have access to. This, at least to me, seems to be the most flexible solution? > > What to do if an address does not unique identify a PvD is another > matter. For both of these issues I'm hoping to have some discussion > in Friday's mif meeting. > =20 > > P.S. When I'm discussing these issues I'm thinking about general > Linux Workstation, like Fedora, and in addition I'm also I'm in > terms of network name spaces as the way to implement PvD separation= =2E > > > FWIW, for Android's mif implementation network namespaces were > considered and rejected. Among other things, I don't think it's > really possible to write an application that can have multiple sockets > with each one "bound" to a different network namespace. That's interesting. Namely, I wrote a test application that does the following: 1. creates a socket (just calls socket function) in the default namespace= 2. then, it switches to some other namespace using setns. This new namespace doesn't have any connectivity. 3. test application connects to a server and issues HTTP GET request 4. writes response to the stdout In short, this worked which made us conclude that the socket is bound to whatever namespace was active at the time socket was created. Application can switch to other namespaces after that at will, even within a single thread. This means that you can use multiple namespaces from within the single application at will. You have to only take care to activate namespace you need before issuing socket call. Did you try to do something like that? The issue we have though, with respect to namespaces, is that we might end up in a situation in which two namespaces share the same IP address. It is almost equivalent to having two machines on the network with the same IP address. We have some half-baked ideas for solutions for this issue, and nothing that works. > > Instead, it's a bit more like implicit PvDs are used with one > interface belonging to one and only one PvD and each PvD gets its own > routing table. This model is, obviously, not as general as mif work > is trying to address (i.e. m:n interfaces to PvDs are not supported). > (but it has been sufficient to gain some experience with how an API > would look and behave) This probably could work for Android, but this brings up two points when we talk about some general Linux distribution: 1. Is it really necessary to support multiple interfaces with a single PvD instance? And by single PvD instance I mean PvD with the same parameters, i.e. same address on multiple interfaces. In that case it seems to me that bridging is a better approach. 2. How do you intend to control which process uses which interface/PvD? SG --------------040503090709050602040007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 04.11.2015 13:01, Erik Kline wrote:=


On 2 November 2015 at 22:13, Stjepan= Gro=C5=A1 <stj= epan.gros@fer.hr> wrote:
=

On 02.11.2015 13:18, Erik Kline wrote:

On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 <stjepan.gros@fer.hr> wrote:
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

Not quite: they should be able to specify only one PvD per function call, per thread (for example).=C2=A0 An app can have multiple= sockets, each one using one PvD.=C2=A0 An app= can have something like a single unconnected datagram socket and call sendto() with a different PvD for each sendto() call.=C2=A0 T= hat kind of thing is more what I meant to write, but I guess was not very clear. =C2=A0(Clearl= y, I have a bunch of sockets-y things in my head but am trying to write things in a more general, non-sockets-dependent way.)

The confusion may be arising in part from the resolution of which PvD to use for a given function call if no PvD is specified.=C2= =A0 In those cases, the system checks for "defaults" at increasingly general levels.=C2= =A0 So a process could set a process default PvD and avoid having to specify the PvD for each an every call, but still make individual socket calls or query DNS on a different PvD whenever it wants to.

Does this make more sense?

 I was thinking on functions like sctp_bindx that explicitly expect multiple IP addresses to be present at a point when the function is called. mpTCP could be even bigger problem because, as I understand it, Linux kernel autonomously decides which local IP addresses to use.

Ah, thank you, that kind of call is an important consideration.=C2=A0 I believe I have a solution that will work: when determining the intended PvD in the case of existing APIs that specify source addresses (and/or maybe even interfaces) we should use PvDs that are uniquely identified by this information.

You mean like having some separate function which is called before sctp_bindx with the same arguments so that appropriate PvDs can be activated?

We were thinking about some kind of a PvD activation function (e.g. pvd_attach_pvd(pvdid *id) and possibly also pvd_detach_pvd) so that application can attach any combination of PvDs it wants to have access to. This, at least to me, seems to be the most flexible solution?


What to do if an address does not unique identify a PvD is another matter.=C2=A0 For both of these issues I'm hopin= g to have some discussion in Friday's mif meeting.
=C2=A0
P.S. When I'm discussing these issues I'm thinking about general Linux Workstation, like Fedora, and in addition I'm also I'm in terms of network name spaces as the way to implement PvD separation.


FWIW, for Android's mif implementation network namespaces were considered and rejected.=C2=A0 Among other things, I don't think it's really possible to write an application that can have multiple sockets with each one "bound" to a different network namespace.

That's interesting. Namely, I wrote a test application that does the following:

1. creates a socket (just calls socket function) in the default namespace
2. then, it switches to some other namespace using setns. This new namespace doesn't have any connectivity.
3. test application connects to a server and issues HTTP GET request<= br> 4. writes response to the stdout

In short, this worked which made us conclude that the socket is bound to whatever namespace was active at the time socket was created. Application can switch to other namespaces after that at will, even within a single thread. This means that you can use multiple namespaces from within the single application at will. You have to only take care to activate namespace you need before issuing socket call.

Did you try to do something like that?

The issue we have though, with respect to namespaces, is that we might end up in a situation in which two namespaces share the same IP address. It is almost equivalent to having two machines on the network with the same IP address. We have some half-baked ideas for solutions for this issue, and nothing that works.


Instead, it's a bit more like implicit PvDs are used with one interface belonging to one and only one PvD and each PvD gets its own routing table.=C2=A0 This model is, obviously, not as general as mif work is trying to address (i.e. m:n interfaces to PvDs are not supported). =C2=A0(but= it has been sufficient to gain some experience with how an API would look and behave)

This probably could work for Android, but this brings up two points when we talk about some general Linux distribution:

1. Is it really necessary to support multiple interfaces with a single PvD instance? And by single PvD instance I mean PvD with the same parameters, i.e. same address on multiple interfaces. In that case it seems to me that bridging is a better approach.

2. How do you intend to control which process uses which interface/PvD?

SG

--------------040503090709050602040007-- --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWOifsAAoJELZD5ReLhUf0/w0IAKj3EEW/ordhZQOhGIX5/mKq B3xFEYdkEtJMaojVw/BUBTfFSb9Gnn8GXtaXcl3fNiV7R8FtIlMs3H97h0StERCB OYgriYiciC8PRPS60MCDhQVYmNVGEYGzyOoTxpt3lETcu3zxAwcBllwqbaYAbBGP +MS9Alh8AVwjDHpcD6qo2S8MzSt32hcJmKQ2AIP1bERLVvQmNpGC5zE7NbgQjxhN PT9a5Wt/UimQypXTgZD4UGC2D0YwaVa6uSVDhlRGxMn7I5LN6kF1jtMx3mQBb/kj 0KmvlSetGsPpUQeoVlUDwuzjgH+NeSB7V0urkI8jpUXHtIbNIMUQf2XiWbkQalU= =4YCb -----END PGP SIGNATURE----- --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo--