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