Re: [Mpvdapi] MIF API Design Team
Erik Kline <ek@google.com> Mon, 06 July 2015 13:46 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 5993B1A90B3 for <mpvdapi@ietfa.amsl.com>; Mon, 6 Jul 2015 06:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.498
X-Spam-Level: ****
X-Spam-Status: No, score=4.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 5qjw3brMlKo4 for <mpvdapi@ietfa.amsl.com>; Mon, 6 Jul 2015 06:46:23 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 3532D1A6EDE for <mpvdapi@ietf.org>; Mon, 6 Jul 2015 06:46:23 -0700 (PDT)
Received: by wgck11 with SMTP id k11so140879683wgc.0 for <mpvdapi@ietf.org>; Mon, 06 Jul 2015 06:46:22 -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=+60Bpe/co+tDfru9j3wSDp4b777OjluMiOAw0bFoiok=; b=kpatt3xKcNHA0z0LRJZy6AtNGSlxYL6YixwpBBCHpFaAKazVbTGDmdJE57WaNYVRw0 qhK7St+b0h/9/GxC70OJEoxyI1659UGM+q8iPoob0GDzaItQWzGnM+WYwHH5czNohs7P f7iJ4zuqk66tF8e40n2sjklXc4wBynQAoyIgg27WUUCSS0dfSWEYWxmShkeJQFyKhb7O QspC9QI4rxXfbYPtJyPIQs/51mo54lGrMUbwTekw1NFNCC5LcUcQ7Nk7M5Vr8L76/Elu rQKj4CSI27scBaZeZ4Qy/osii6AMpiyQvxecnavY4dUMuZlKV6grmS10KDJf8rynKV7N IFQw==
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=+60Bpe/co+tDfru9j3wSDp4b777OjluMiOAw0bFoiok=; b=Pccr9UrR/OypbdNN731b45Qb9yslWSncI4deOD93+vOT+4UWUmt8HAPLZJWCaRjzWS WWVJDfc2gyJyQ5hxBMngW2kjGzH8DfiYICWLwtO4FJ34S3u6yWGujfAmJHnTVnu9ljVp zQtlV74E7MsVR4N1s+pEzsjTlwidQ+pTfiVJJfQUB6c+AlwoenjAqs1p22ipKwtjz/Mu LwhSQVdxabaN6gWjaT72LJyBf40nfhsdHHFT+K4Jrnw4amRjmwuargPzz6jYBaPMsbMz 0rrdkomh1X2PsV/SboxnyeEtTflbrM8Uk0ukoWpxWkZNKAf3revJ6HA+LRNbpvBy3nvm o2vQ==
X-Gm-Message-State: ALoCoQnQJr3ZyAY3KYVXjuNqskIrJpoAl2TE1IS9YyVYhlgURexct1RXVMlIdPivmmvVLnjHMLQC
X-Received: by 10.181.27.131 with SMTP id jg3mr87649379wid.89.1436190381871; Mon, 06 Jul 2015 06:46:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.138.203 with HTTP; Mon, 6 Jul 2015 06:46:02 -0700 (PDT)
In-Reply-To: <BC86DD16A1884530A01FE2085D89BAC6@gmail.com>
References: <COL125-W682E88CBC847DB5A2AAD3B1930@phx.gbl> <BC86DD16A1884530A01FE2085D89BAC6@gmail.com>
From: Erik Kline <ek@google.com>
Date: Mon, 06 Jul 2015 22:46:02 +0900
Message-ID: <CAAedzxpeS=Pu69nQqWoU=c_gQgxY5SVrGWcWju8djN-eU77DhA@mail.gmail.com>
To: Dapeng Liu <maxpassion@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpvdapi/JBYpiuRuRVyGLKqGnzsbwsaTi-U>
Cc: Margaret <margaretw42@gmail.com>, Mikael Abrahamsson <mikael.abrahamsson@t-systems.com>, Hui Deng <denghui02@hotmail.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: Mon, 06 Jul 2015 13:46:26 -0000
Alright, I'm not gonna make it by tomorrow morning (too many work issues). Dapeng's document explicitly describes a struct pvdinfo. I like it, but I fear it won't be extensible if we, for example, decide in the future that a Foo Protocol Server is an essential piece of configuration information. Did you get a chance to think about the pvd_handle_t idea? It means we might end up with an ioctl-like call, were you would write: getpvdinfo(pvd_handle_t, PVD_INFO_FOOSERVERS, (void*)&foo_struct) and portable code can test for the existence of PVD_INFO_FOOSERVERS. Not the prettiest though. :( Some of the things are not trivially represented, either. Consider how you would represent routes learned from various RIOs that make up the pvd configuration. On 6 July 2015 at 16:31, Dapeng Liu <maxpassion@gmail.com> wrote: > 在 2015年7月6日 星期一,下午3:04,Hui Deng 写道: > > 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 > > > Hi Hui, > > Sure. > The draft is used used for the design team’s reference since it has some > similarity with what Eric proposed in the list. > > Thanks, > Dapeng Liu > > > 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 > > >
- 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