Re: [Mpvdapi] MIF API Design Team
Erik Kline <ek@google.com> Mon, 15 June 2015 10:55 UTC
Return-Path: <ek@google.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 883141A1A78 for <mpvdapi@ietfa.amsl.com>; Mon, 15 Jun 2015 03:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 5.299
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, 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 IlsQ_9Ivr6dj for <mpvdapi@ietfa.amsl.com>; Mon, 15 Jun 2015 03:55:38 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342B91A1A92 for <mpvdapi@ietf.org>; Mon, 15 Jun 2015 03:55:38 -0700 (PDT)
Received: by wiwd19 with SMTP id d19so71047383wiw.0 for <mpvdapi@ietf.org>; Mon, 15 Jun 2015 03:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=gqjZO5jMdA23PzEabHxJxPvI1IrWQRZekYFTedZ8/bo=; b=LDyww+Orxe0UU7Q6hG9tB4fVI2Ofz0bb6hITRbJwxdthLO7h2nC6861gy5+wlBNsto mtQOf++CbxAliW2tc52OlCMLAFsrtxQSgPEEMO1pYw2Fn4HO/5q4IZ1OmTLl+pmL1v4E dU9Yq5zLXb8Yi8CfV+DpkhGVCf5XhA8ByAlslJbmWBLKXeP73sgoyptaDDUxqDJqUq8I baeqifwsD5NX6lRNg1YjkMG9VCNMaIqRWJ1BymUHZojeAA5iGis27lKPj3pzYuZOxofM /g1DuBoaML0xoOo3+jVC/wjOso5I7MmpibMBBNMUYzVHDTdAhfw3mWKhcYwa4HktuWv0 B3vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gqjZO5jMdA23PzEabHxJxPvI1IrWQRZekYFTedZ8/bo=; b=jf1PNpBwzkwtrpW4gihL91Smgzpa2Msb06fzz29+KtiqyOsyaG54cHotHWeAuXTkkV k7TxkdThzexcH/bgR4t3ORpOdflUiDKx3fOStmPyYm3mKBvv9BxZ+24Ieln61qOPQZhJ v4gPObIBDFAoeJvyx9ruPGwTUe+/gM7LwjQPJFKz+agYPsBkc3QN965V7DuDfrE3ITJB rPq1xH0d0u00e2suhXClb5KSyuqGnuZsXo4aXpjZXEpE9wQcLYqFa/zmX9jpZp04dlkp ZczBqy0TX8WRuRw+pGBnADmiZiyI0AbTNirNc/mKJJqawkWgOTf7ym7MMofriubRvqqp 5RwA==
X-Gm-Message-State: ALoCoQlCfhHB7jS8XTL182kfXMuyvKNRXI/NGLFpxHWFIQfFidD1qblhwLFxCcIbHp3VrWjthiFt
X-Received: by 10.194.90.171 with SMTP id bx11mr48575121wjb.129.1434365736672; Mon, 15 Jun 2015 03:55:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.146.3 with HTTP; Mon, 15 Jun 2015 03:55:15 -0700 (PDT)
In-Reply-To: <COL125-W167CB51F442EC1F8DB55C7B1BF0@phx.gbl>
References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <COL125-W167CB51F442EC1F8DB55C7B1BF0@phx.gbl>
From: Erik Kline <ek@google.com>
Date: Mon, 15 Jun 2015 19:55:15 +0900
Message-ID: <CAAedzxqBweZ2gOBqPFNa4UJkJjScYUXfxEY6xKL_2mhouaF3nQ@mail.gmail.com>
To: Hui Deng <denghui02@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpvdapi/Bi85viZyhzwLDSZHhsMRtDNvrHc>
X-Mailman-Approved-At: Mon, 15 Jun 2015 05:31:34 -0700
Cc: Mikael Abrahamsson <mikael.abrahamsson@t-systems.com>, 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: <http://www.ietf.org/mail-archive/web/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: Mon, 15 Jun 2015 10:55:40 -0000
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
- Re: [Mpvdapi] MIF API Design Team Erik Kline
- Re: [Mpvdapi] MIF API Design Team Hui Deng
- [Mpvdapi] 回复: MIF API Design Team Dapeng Liu
- [Mpvdapi] 回复: MIF API Design Team Dapeng Liu
- Re: [Mpvdapi] 回复: MIF API Design Team Hui Deng
- Re: [Mpvdapi] 回复: MIF API Design Team Erik Kline
- [Mpvdapi] 回复: MIF API Design Team Dapeng Liu
- Re: [Mpvdapi] MIF API Design Team Erik Kline
- Re: [Mpvdapi] MIF API Design Team Hui Deng