[Mpvdapi] 回复: MIF API Design Team

Dapeng Liu <maxpassion@gmail.com> Mon, 06 July 2015 06:25 UTC

Return-Path: <maxpassion@gmail.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 0E7C51A89C6 for <mpvdapi@ietfa.amsl.com>; Sun, 5 Jul 2015 23:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.689
X-Spam-Level: ***
X-Spam-Status: No, score=3.689 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 5Cj7ASdUP_Al for <mpvdapi@ietfa.amsl.com>; Sun, 5 Jul 2015 23:25:19 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 039C51A89A9 for <mpvdapi@ietf.org>; Sun, 5 Jul 2015 23:25:19 -0700 (PDT)
Received: by pabvl15 with SMTP id vl15so90225388pab.1 for <mpvdapi@ietf.org>; Sun, 05 Jul 2015 23:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=s23EFHcL/s/P/IUZLyW7yedO2dD+QKqPVIF7+Dsa2MQ=; b=oXDTDER6ojgmNrWTWSjGJmGdS5MZb2QbKAUWEWQ1FRdqU0N/hHNRRvWKlSAOqhzlx7 U7NFt4XvCSY9/FaqNe3GoxCsYJeJYz94zk39YPdLhMw9VazARHlOZV1mQF9gH6X70Hxr 7hJLnjEolQi1oSW78BI/Ji570UFKCA92M1DZB48yQ6erusNdvVDfWxXRoyxcVb71Lhkj Qlpd1lVfF2o7TPkxHydho+UndQvo/lsshsS4OmPALWDGgSggbyWMqmg6cuEutB3ysvOy l5sT5dQvPVu7S7lHMfIvKC2eXMhW/zzrlCp0iF4escwxgo5Sy4Vini93CS0Ou7yKZk5Z 33OQ==
X-Received: by 10.70.88.43 with SMTP id bd11mr100540912pdb.7.1436163918587; Sun, 05 Jul 2015 23:25:18 -0700 (PDT)
Received: from [10.1.50.207] ([202.55.20.10]) by mx.google.com with ESMTPSA id ho10sm16847666pbc.27.2015.07.05.23.25.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 Jul 2015 23:25:17 -0700 (PDT)
Date: Mon, 06 Jul 2015 14:25:12 +0800
From: Dapeng Liu <maxpassion@gmail.com>
To: Hui Deng <denghui02@hotmail.com>
Message-ID: <D895565D8B034C2AB0AA65AD259C7BF6@gmail.com>
In-Reply-To: <2DF18DBB97774B22A8D78C461ACED61B@gmail.com>
References: <5E6BCAD4-0F0E-42B1-B9DB-BE847A04863D@gmx.com> <COL125-W167CB51F442EC1F8DB55C7B1BF0@phx.gbl> <,> <CAAedzxqBweZ2gOBqPFNa4UJkJjScYUXfxEY6xKL_2mhouaF3nQ@mail.gmail.com> <COL125-W153BDE4DB5FFACFCEEED06B1940@phx.gbl> <2DF18DBB97774B22A8D78C461ACED61B@gmail.com>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="559a1f48_74b0dc51_1656"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpvdapi/QhDigwZmP7HZ6WZWYajKKOl6XLE>
Cc: Erik Kline <ek@google.com>, Mikael Abrahamsson <mikael.abrahamsson@t-systems.com>, Margaret <margaretw42@gmail.com>, "mpvdapi@ietf.org" <mpvdapi@ietf.org>, Ian Farrer <ianfarrer@gmx.com>
Subject: [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 06:25:23 -0000

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 (mailto:ek@google.com)
> > > Date: Mon, 15 Jun 2015 19:55:15 +0900
> > > Subject: Re: MIF API Design Team
> > > To: denghui02@hotmail.com (mailto:denghui02@hotmail.com)
> > > CC: ianfarrer@gmx.com (mailto:ianfarrer@gmx.com); mikael.abrahamsson@t-systems.com (mailto:mikael.abrahamsson@t-systems.com); mpvdapi@ietf.org (mailto: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 (mailto: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 (mailto:ianfarrer@gmx.com)
> > > >> Subject: MIF API Design Team
> > > >> Date: Mon, 8 Jun 2015 14:07:02 +0200
> > > >> CC: mikael.abrahamsson@t-systems.com (mailto:mikael.abrahamsson@t-systems.com)
> > > >> To: denghui02@hotmail.com (mailto: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 (mailto:Mpvdapi@ietf.org)
> > https://www.ietf.org/mailman/listinfo/mpvdapi
> >  
> >  
> >  
>  
>  
>  
> 附件:  
> - draft-liu-mif-socket-api-00.txt
>