Re: [Mpvdapi] 回复: MIF API Design Team

Erik Kline <ek@google.com> Mon, 06 July 2015 07:21 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 327E41A3B9F for <mpvdapi@ietfa.amsl.com>; Mon, 6 Jul 2015 00:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.299
X-Spam-Level: ****
X-Spam-Status: No, score=4.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, 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 5yFOoaIhnZfc for <mpvdapi@ietfa.amsl.com>; Mon, 6 Jul 2015 00:21:00 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 5BD3E1A1EEE for <mpvdapi@ietf.org>; Mon, 6 Jul 2015 00:21:00 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so144079611wib.1 for <mpvdapi@ietf.org>; Mon, 06 Jul 2015 00:20:59 -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=RURT9q7bWqNcvzVa6gDTKVlWbw+9tRsOsxIajfXlaP0=; b=T/OVld2QRxQihs14SyJppntOuy+RZv+O47VPWgwHjPXUmhWPxBOmYX1Fe1z1TxbjNA u1CiYGw1duDVE/+7CvuOSGrMWrAmFepa4226vMwDKGwNmRz+s0BDryCMFL1TkWq8Ix+g aANjOcr8vMDpHk+O198l665HTbVcRXfn90zyBCUFL1lpXQIyzu0s3AGCiuVLK6ujrrIK mo2+37Yupk4AIoFP8pr2oW00FTVOTGysY/K9hAiuvjgiP4cgDvj8UhYXS0V61jXkGpvr MEk/TsTRencVuNKYlnuOiIL7Ym27OSadYmUKG3TdoxeJixDsC4NCtkZ3NBHv65aZhFyK QmUA==
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=RURT9q7bWqNcvzVa6gDTKVlWbw+9tRsOsxIajfXlaP0=; b=HOVYTra6XE4Y/DWc7iaH8ZeXrYZBYjDFqYXPC/drNqIePXd6oSzudQ34aghq7xPvkh uC4x3Q+P+Fgdy6HnlQBgpux2gI8NyJhkOsRuF/apGkLIgLPSqtFZ7AOZbTkAfDBagfNZ Cup3EAuHAB/HE9w0TTDg7/TBI7lBoWPNb3IEj4B77gzIiMuWjgOBOSpHTzy/zmkbNAJJ 5oIczcUThgqb3LqDPKUyBDuS7RlgRSc3A/3fnixwa5VfPkGwhjxoTV4TaOGzA2vM3uJH O0v6GQflcyT3SVz3nyKD1hF9Lds7PJIJnaHg/4mY8W30WIxJQGl+MBWvizkuNeXbHnba jpcg==
X-Gm-Message-State: ALoCoQmPlFWxm/sGnZTaGt3MICMS5lMmkRZgBvYPtu8vkkBaSa9u7DtlmeLXaRWybvSOYJIu+AAf
X-Received: by 10.180.78.136 with SMTP id b8mr48711311wix.89.1436167258991; Mon, 06 Jul 2015 00:20:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.138.203 with HTTP; Mon, 6 Jul 2015 00:20:39 -0700 (PDT)
In-Reply-To: <COL125-W682E88CBC847DB5A2AAD3B1930@phx.gbl>
References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <COL125-W167CB51F442EC1F8DB55C7B1BF0@phx.gbl> <CAAedzxqBweZ2gOBqPFNa4UJkJjScYUXfxEY6xKL_2mhouaF3nQ@mail.gmail.com> <COL125-W153BDE4DB5FFACFCEEED06B1940@phx.gbl> <2DF18DBB97774B22A8D78C461ACED61B@gmail.com> <D895565D8B034C2AB0AA65AD259C7BF6@gmail.com> <COL125-W682E88CBC847DB5A2AAD3B1930@phx.gbl>
From: Erik Kline <ek@google.com>
Date: Mon, 6 Jul 2015 16:20:39 +0900
Message-ID: <CAAedzxoxOXyqkmLK0cV0zHG8_PmKda03LJ76vOApKyWdP82fpw@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/l6v_oGd6PTDpsoy0m66Ey2ECGgU>
Cc: Mikael Abrahamsson <mikael.abrahamsson@t-systems.com>, Ian Farrer <ianfarrer@gmx.com>, Margaret <margaretw42@gmail.com>, "mpvdapi@ietf.org" <mpvdapi@ietf.org>, Dapeng Liu <maxpassion@gmail.com>
Subject: Re: [Mpvdapi] =?utf-8?b?5Zue5aSN77yaICBNSUYgQVBJIERlc2lnbiBUZWFt?=
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: Mon, 06 Jul 2015 07:21:03 -0000

I will take the notes I sent out and reformat them into a draft before
the deadline.  We can sync up in Prague and decide what to do and how
to merge, etc...

On 6 July 2015 at 16:04, Hui Deng <denghui02@hotmail.com>; wrote:
> Hi Dapeng
>
> At this moment, we would expect that Erik could lead this MIF MPVD API
> design tem, please try to contribute the design team work from your draft.
> thanks a lot for your cooperation
>
> Best regards,
>
> DENG Hui
>
>
> ________________________________
> Date: Mon, 6 Jul 2015 14:25:12 +0800
> From: maxpassion@gmail.com
> To: denghui02@hotmail.com
> CC: ek@google.com; margaretw42@gmail.com; mikael.abrahamsson@t-systems.com;
> mpvdapi@ietf.org; ianfarrer@gmx.com
> Subject: 回复: [Mpvdapi] MIF API Design Team
>
>
> The updated version: https://tools.ietf.org/html/draft-liu-mif-socket-api-00
>
> --
> Dapeng Liu
>
> 在 2015年7月5日 星期日,下午6:53,Dapeng Liu 写道:
>
> Hi Hui and Erik,
>
> Attachment is the draft I mentioned during the discussion. It was written
> before the Dallas meeting and it may not reflect the latest consensus we
> have.
>
> I am trying to update it.
>
>
>
> --
> Dapeng Liu
>
> 在 2015年7月5日 星期日,下午3:27,Hui Deng 写道:
>
> 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
> _______________________________________________
> Mpvdapi mailing list
> Mpvdapi@ietf.org
> https://www.ietf.org/mailman/listinfo/mpvdapi
>
>
>
> 附件:
> - draft-liu-mif-socket-api-00.txt
>
>