Re: [Mpvdapi] MIF API Design Team

Hui Deng <denghui02@hotmail.com> Sun, 05 July 2015 07:27 UTC

Return-Path: <denghui02@hotmail.com>
X-Original-To: mpvdapi@ietfa.amsl.com
Delivered-To: mpvdapi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686931B2C13 for <mpvdapi@ietfa.amsl.com>; Sun, 5 Jul 2015 00:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 5.029
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.029 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 fRg144UHCnpI for <mpvdapi@ietfa.amsl.com>; Sun, 5 Jul 2015 00:27:06 -0700 (PDT)
Received: from COL004-OMC4S14.hotmail.com (col004-omc4s14.hotmail.com [65.55.34.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1EB1B2C10 for <mpvdapi@ietf.org>; Sun, 5 Jul 2015 00:27:06 -0700 (PDT)
Received: from COL125-W15 ([65.55.34.200]) by COL004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 5 Jul 2015 00:27:06 -0700
X-TMN: [bSjCttxEF2eCm8z+1/GITeSglsJSIwS+]
X-Originating-Email: [denghui02@hotmail.com]
Message-ID: <COL125-W153BDE4DB5FFACFCEEED06B1940@phx.gbl>
Content-Type: multipart/alternative; boundary="_d37a9a98-87bf-49db-a137-6fdf2437059c_"
From: Hui Deng <denghui02@hotmail.com>
To: Erik Kline <ek@google.com>, Margaret <margaretw42@gmail.com>
Date: Sun, 05 Jul 2015 15:27:06 +0800
Importance: Normal
In-Reply-To: <CAAedzxqBweZ2gOBqPFNa4UJkJjScYUXfxEY6xKL_2mhouaF3nQ@mail.gmail.com>
References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <COL125-W167CB51F442EC1F8DB55C7B1BF0@phx.gbl>, <CAAedzxqBweZ2gOBqPFNa4UJkJjScYUXfxEY6xKL_2mhouaF3nQ@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jul 2015 07:27:06.0422 (UTC) FILETIME=[FEF06560:01D0B6F3]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpvdapi/GWWNH_h_WNC_7ExB6JRbhnPLu5w>
X-Mailman-Approved-At: Sun, 05 Jul 2015 00:28:54 -0700
Cc: Mikael Abrahamsson <mikael.abrahamsson@t-systems.com>, "mpvdapi@ietf.org" <mpvdapi@ietf.org>, Ian Farrer <ianfarrer@gmx.com>
Subject: Re: [Mpvdapi] MIF API Design Team
X-BeenThere: mpvdapi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <mpvdapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpvdapi>, <mailto:mpvdapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpvdapi/>
List-Post: <mailto:mpvdapi@ietf.org>
List-Help: <mailto:mpvdapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpvdapi>, <mailto:mpvdapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jul 2015 07:27:13 -0000

Hi Erik
 
I guess that everbody is busy with deadline,
could you kindly help to write down a draft about this proposal and then present it during coming MIF sesson, 
then we get more people to review on how Android implement this.
 
Thanks a lot for your kind work
Best regards,
 
DENG Hui
 
> From: ek@google.com
> Date: Mon, 15 Jun 2015 19:55:15 +0900
> Subject: Re: MIF API Design Team
> To: denghui02@hotmail.com
> CC: ianfarrer@gmx.com; mikael.abrahamsson@t-systems.com; mpvdapi@ietf.org
> 
> Sorry about that: it's back to back 3GPP and now Android release issues.
> 
> I spent the weekend reworking some notes on the things I described in
> Dallas.  That's not coming together quickly enough so let me lay
> everything out here instead.  In so doing I will try to describe more
> about the approach Android took to see if people even think it makes
> sense.
> 
> Let's assume for the sake of argument that C API definitions are
> nicely isolated, maybe in some #include <netpvd.h> header file.
> 
> [1] Provisioning domains are represented by a "handle" kind of class,
> android.net.Network:
> 
>     https://developer.android.com/reference/android/net/Network.html
> 
> These are essentially handles to identify instances of attaches to
> provisioning domains.  The underlying identifier values are not
> recycled (except after a really long time).  Multiple temporally
> disparate attaches to the same network each get a new instance
> value--we have not yet found it of value to try to de-duplicate
> attaches.  Applications that want to know if you're attached to
> "Starbucks" so they can startup and auto-sign-in use the relevant
> handle value to query parameters (like SSID).
> 
> I would propose that a C API would have something like
> 
>     typedef uint64_t pvd_handle_t
>     #define PVD_HANDLE_UNSPEC ((pvd_handle_t)0)
> 
> [2] Once an application has received a Network handle [let's save how
> that happens for later] it can request that certain operations be
> performed specifically within the associated PVD.  Currently these
> operations include:
> 
>     [bind a file descriptor to a PVD to force packets to be sent using
> the PVD's routing table]
>     android.net.Network#bindSocket()
>     https://developer.android.com/reference/android/net/Network.html#bindSocket(java.net.Socket)
> 
>     [perform DNS lookups using a PVD's DNS servers]
>     android.net.Network#getAllByName()
>     https://developer.android.com/reference/android/net/Network.html#getAllByName(java.lang.String)
> 
>     [set the PVD for all file descriptors and DNS lookups for a
> process, unless otherwise overridden]
>     android.net.ConnectivityManager#setProcessDefaultNetwork()
>     https://developer.android.com/reference/android/net/ConnectivityManager.html#setProcessDefaultNetwork(android.net.Network)
> 
> I would propose that a C API have at least the following:
> 
>     [a] get/setsockopt(int fd, SOL_SOCKET, SO_PVD_HANDLE, &pvd_handle_t);
>     [b] getaddrinfo/getnameinfo some taking a pvd_handle_t
>     [c] discussion of recvmsg/sendmsg/accept semantics
> 
> Note that the last is particularly tricky.  Operating systems need to
> know how to "mark" incoming packets that would cause a new connection
> such that they have the correct pvd_handle_t associated.  This has
> lots of impact on suitable address selection as well.
> 
> The C API should also have at least the following:
> 
>     [d] system, process, and per-thread pvd_handle get/set calls
> 
>     // These values are used by PVD-aware function calls when a PVD index
>     // is not explicitly specified.
>     pvd_handle_t pvd_system_default();
> 
>     // Same as above, but operates at a per-process level.  If no
>     // process-specific default has been set this MUST return the value
>     // of a call to pvd_system_default().
>     pvd_handle_t pvd_process_default();
> 
>     // Same as above, but operates at a per-thread level.  If no
>     // thread-specific default has been set this MUST return the value
>     // of a call to pvd_current_process_default().
>     pvd_handle_t pvd_thread_default();
> 
>     int pvd_set_system_default(pvd_handle_t);  // 0 or -1 && errno = EFOO
>     int pvd_set_process_default(pvd_handle_t);  // 0 or -1 && errno = EFOO
>     int pvd_set_thread_default(pvd_handle_t);  // 0 or -1 && errno = EFOO
> 
>     [e] good discussion of a variety of EFOO errno return values.
> 
> When a PVD has gone away (e.g. we disconnected from WIFI), subsequent
> operations on the associated pvd_handle should fail with errno =
> ENONET.
> 
>     [f] good discussion of how the process and thread default values
> behave across fork/exec
> 
> FWIW, Android uses all of the above when NetworkMonitor is validating
> a network--it does DNS lookups within the PVD, makes pvd-bound sockets
> used for HTTP Direct or Proxy connections to check connectivity to a
> URL:
> 
>     https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/connectivity/NetworkMonitor.java
> 
> [3] the device has to build up configuration data continuously over
> time, as DHCP results come back, and RAs come in bringing new prefixes
> or new DNS servers.
> 
> Not that it's relevant, but Android accumulates these in an
> android.net.LinkProperties object:
> 
>     https://developer.android.com/reference/android/net/LinkProperties.html
> 
> as we currently only support a 1:1 mapping of PVDs to physical interfaces.
> 
> The means by which the operating system allocates pvd_handles, gathers
> this data and associates it with a pvd_handle (including marking
> incoming packets that would causes a new connection) might best be
> left for a separate document, since sections 1 and 2 and background
> theory will require a fair amount of text.
> 
> [4] Android lets processes register callbacks to be called when
> certain network properties change, or when a new network shows up, or
> one goes away.  This is how applications receive the handles (Network
> objects).
> 
> The UNIX way of doing these sorts of things...well, frequently leaves
> much to be desired...but we should support multiple event-driven
> models, I think.
> 
> [5] we'll want an API for an application to pass in a handle and get
> an ever expanding list of parameters (expanding as we think to add
> them and write documents about them).
> 
> The Android ConnectivityManager mitigates all this stuff and passes
> around NetworkInfo objects which encapsulate extra information like
> SSIDs, whether the Network is Ethernet, Mobile, Wi-Fi, or whether it's
> metered, and so on.
> 
> The closest UNIX-style analogy here would be some interface that is
> getsockopt()-like, I think.  Something like:
> 
>     int pvd_get_attribute(pvd_handle_t, PVD_ATTR_(HWTYPE|METERED|...),
> void *returned_blob);
> 
> And then it will be possible for code to be written like
> 
>     #ifdef PVD_ATTR_HTTP_PROXY_URL
> 
>     char proxyString[PVD_ATTR_HTTP_PROXY_URL_MAXLEN];
>     memset(proxyString, 0, sizeof(proxyString));
>     if (!pvg_get_attribute(pvd_handle, PVD_ATTR_HTTP_PROXY_URL, proxyString)) {
>         perror("Sadness!");
>         return -1;
>     }
> 
>     #endif
> 
> 
> ---
> 
> That's a massive brain dump, and I apologize for it and also that it's so late.
> 
> Let me know what y'all think.
> -Erik
> 
> On Mon, Jun 8, 2015 at 11:18 PM, Hui Deng <denghui02@hotmail.com> wrote:
> > Hi Erik
> >
> > We are waiting for your lead to start this work asap. Feel free to us know
> > when you are ready.
> >
> > Hi Ian, thanks  a  lot for letting us know that you are going to work with a
> > university on the implementations.
> > Erik was quite busy for 3GPP SA2 work recently, we are waiting for his
> > return to lead the work.
> >
> > Best regards,
> >
> > DENG Hui
> >
> >
> >> From: ianfarrer@gmx.com
> >> Subject: MIF API Design Team
> >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> >> CC: mikael.abrahamsson@t-systems.com
> >> To: denghui02@hotmail.com
> >>
> >> Hi Hui,
> >>
> >> My apologies for not being in contact sooner. Things don’t always move as
> >> quickly as hoped around here!
> >>
> >> The current status is that we have provisionally obtained the necessary
> >> resources to start working on a proof of concept implementation of the MIF
> >> architecture. We will be doing this in partnership with a University.
> >>
> >> Tomorrow (9th July) we will start the scoping work with the implementor.
> >> What I want to come out of this work is a proof of concept implementation of
> >> the MIF architecture on a ‘generic’ Linux based platform. As Eric is working
> >> on an Android implementation for the mobile use case, I think that this
> >> should complement his work quite well and serve to provide some good
> >> implementation experience which can be fed back into the update of the MIF
> >> API document.
> >>
> >> I’ve sent a subscription request to the MIF API design team mailing list.
> >> Once we’ve got some firmer details agreed with the implementors, I’ll make
> >> an announcement on the m/l of what we’re doing and we can discuss what the
> >> best way of aligning the two implementation efforts.
> >>
> >> Best regards,
> >> Ian