Re: [alto] unified-props, cellular addresses and path-vector

Jensen Zhang <jingxuan.n.zhang@gmail.com> Thu, 01 March 2018 07:22 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADD012D96B for <alto@ietfa.amsl.com>; Wed, 28 Feb 2018 23:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Zx6D83h75Fq4 for <alto@ietfa.amsl.com>; Wed, 28 Feb 2018 23:22:04 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 4D9C11205D3 for <alto@ietf.org>; Wed, 28 Feb 2018 23:22:04 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id i13-v6so1824201ybl.9 for <alto@ietf.org>; Wed, 28 Feb 2018 23:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k1OpuaU8bzsjGe6U8b5z8xad7QKn7mOeUozxF9ac+v4=; b=m2FiVxk5YGSSQYCMyeJB7vUUp8RtgQeTsXyq/dBnGnjFY174AE28jc0DTdmWKBZPwt ELd9u05ZsHNAcdgXxyIbAc9uEPmRc60z3NbYBd48ZnvnrnCcsgi83fUz2RQM4a6rDweR Qc6fl8Dr1ZXyPlU35qtBgyJSD9s7N/SazZiRAtZBK0mRTDaKg75jixaEgbCV3l/jMw/z 67/iDU6WFd50JkVjlVkV/Dk0tx7ItnohvrU/Nq/q3CjlcoRmyhY4zsrXrM5DIxTauI/q OqGb2rlV9zmrSPcamy6FwwH08GlOzYwVJ1o1ncpuWakvYDYRREgnAOaLFlJfNOgcDP6F FYvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k1OpuaU8bzsjGe6U8b5z8xad7QKn7mOeUozxF9ac+v4=; b=WGz1bu8ggDE/SvwkCIcx7HBWzTAYW5kXWiWEpGQUpgPEJcsEI7U8jqy9xQsjNgWs8j UA1qvXKuN6K7kbgp2s24iorkFLqvRbbiPt1U5VvlAUoqSnD13ovnV+47PzNzKgrlS8xU gw1fFCL7aDw9gbLdTYyaEAqjImpVRBkmZv8Fvv3w0L0zKvfUGPAWLbAxTlygcFdpCDki eVKDbWC5yCPls1mMq/JJNrBYJJDmR9dM0xDvwuooQ97ZaeDi/3SxGddCtzRqW01dTQVi mkeSzIobGdFOgIKVELb2HZqpY8XPE0C08L4qBBPLTMINKQbyz0uC4A7dolXa18aua3gk qKbw==
X-Gm-Message-State: APf1xPBatinCA2LSMs6HJOGwwNAjO2cdaIu0laRsE/R14PHNT/3sRQe5 kkxkgDMY0nGb05+XtV8QGl8QYjerNxcGbh6SF2I=
X-Google-Smtp-Source: AG47ELt9IvU/Z04+un7YUGTZigjLIJ309lDS4YpqL3zgzTNDXk/GjPar+rA5xfKTNmWts5obNijcADY3pFvukobJ0Hw=
X-Received: by 2002:a25:e689:: with SMTP id d131-v6mr467219ybh.28.1519888923329; Wed, 28 Feb 2018 23:22:03 -0800 (PST)
MIME-Version: 1.0
References: <5e6a98ff-3c8d-f1b8-2deb-21788cdfef09@nokia.com> <BLUPR02MB1202578B8645F956E30B7066B5CC0@BLUPR02MB1202.namprd02.prod.outlook.com> <CANUuoLrAR=b9b36extXU6Hc6VSv1ExsD7Yze09b8WUnfSnbJCg@mail.gmail.com> <HE1PR0702MB3738F145B3656EEC8E59957795C10@HE1PR0702MB3738.eurprd07.prod.outlook.com> <BN3PR02MB1208138DACA86AFDC47CBAFAB5C00@BN3PR02MB1208.namprd02.prod.outlook.com> <CAAbpuyq7FmpAEBJxO1viHGgHaPgFtLFE02dyZgC-0wHC9zvg8A@mail.gmail.com> <HE1PR0702MB3738C64E297B4AF7C468AF0595C70@HE1PR0702MB3738.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0702MB3738C64E297B4AF7C468AF0595C70@HE1PR0702MB3738.eurprd07.prod.outlook.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Thu, 01 Mar 2018 07:21:52 +0000
Message-ID: <CAAbpuyrA+R+WqRJbPQynhQvtJ5ihm=uWEs6ifDQvsOg3MhG2Xw@mail.gmail.com>
To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
Cc: Dawn Chan <dawn_chen_f@hotmail.com>, "Y. Richard Yang" <yry@cs.yale.edu>, Wendy Roome <wendy@wdroome.com>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f8a63056654b78d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/Wmqia2geXiNjG16Y0o8SmgSn-9o>
Subject: Re: [alto] unified-props, cellular addresses and path-vector
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 07:22:07 -0000

Hi Sabine,

Sorry for the delay. Please see my comments inline.

On Wed, Feb 28, 2018 at 8:54 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com> wrote:

> Hi Dawn and Jensen,
>
>
>
> My 2 cents here,
>
>
>
> Indeed, the text in
> https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01  has
> not been explicitly formatted for the Unified Property draft. However,
> mapping the domain type with “ecgi”, the entities with cells and their
> addresses with the proposed format is kind of straightforward and example
> properties can be imported from
> https://tools.ietf.org/html/draft-randriamasy-alto-cost-context-02
>
>
>
Removing "Section 3.4 ANE Domain" and adding it to Path-Vector and
> registering each new entity domain in a separate WG document in my view may
> generate some dispersion and we may lose track of one of the goals of the
> UP draft which is to broaden the view beyond the ipv6 and ipv4 domains.
>
>
>
The UP draft extends entities from Endpoints to PIDs, ANEs, Cells and other
> potential entities. Path Vector uses ANE as a cost metric and introduces
> composite information resources that couple ANE properties with classical
> Cost Maps.  ANEs, open the way for a richer network description, the ANE
> identification scheme and related property maps may be used in other
> contexts than Path Vector requests.
>
>
>
> I think the UP draft remains a good placeholder to define domains such as
> PID, ANE, ecgi and other future network related domains. Sticking to the
> ipv4 and ipv6 would significantly decrease its novelty. So it is important
> to identify a “central” placeholder where one can register and keep track
> of the evolution of domains beyond ipv4 and ipv6. This does not preclude
> from keeping on proposing new entities in separate drafts with the intent
> of ultimately adding them to the central register.
>
>
>
I understand your point. Of course, we need to highlight the novelty:
extensible. This is one of the design philosophy of UP. So the introduction
wrote:

"Entity domains and property names are extensible. New domains can be
defined without revising the messages defined in this document, in the same
way that new cost metrics and new endpoint properties can be defined
without revising the messages defined by the ALTO protocol."

But I think the another design philosophy of UP should be minimal. The only
reason we define ipv4, ipv6 and pid domain in this draft is that they have
been used in the existing RFCs. But for ANE, esgi and other future network
related domains, they are still not mature. So we need to avoid their
effect to UP.

For example, if you register ecgi as a new *entity domain* in UP now, but
you want to modify the encoding of the esgi *address type* in another
document later, it will introduce unexpected consistency issue.

This is my opinion. We still need comments from Wendy, Richard and other WG
members.


> By the way, the UP design may allow moderating the volume of on the wire
> data exchange if “cross-product” like responses could be avoided.
>
> For instance, similiarly to the flow cost service proposal:
>
> [(entity1, entity4), (propA, propB)
>
> (entity2), (propC)
>
> (entity3), (propD)]
>
>
>
> Instead of [(entity1, entity2, entity3, entity4) X (propA, propB, propC,
> propD)
>
>
>
That's an interesting point. This proposal can reduce the unnecessary
information from the UP's response. My only concern is whether it will
introduce unexpected complexity.

I think such a request can always be equal to multiple separated
"cross-product" requests. It is different from the flow cost service.
Because a single request for correlated flows is not equal to separated
cross-product flow requests. Or can we find an example that such an
improvement is necessary?

We need to collect more feedback from WG.


> Any thoughts?
>
> Thanks,
>
> Sabine
>
>
>
>
>
>
>
>
>
> *From:* Jensen Zhang [mailto:jingxuan.n.zhang@gmail.com]
> *Sent:* Tuesday, February 27, 2018 10:04 AM
> *To:* Dawn Chan <dawn_chen_f@hotmail.com>
> *Cc:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriamasy@nokia-bell-labs.com>gt;; Y. Richard Yang <yry@cs.yale.edu>du>;
> Wendy Roome <wendy@wdroome.com>om>; alto@ietf.org
> *Subject:* Re: [alto] unified-props, cellular addresses and path-vector
>
>
>
> Sabine,
>
>
>
> Just add some additional comments to Dawn's proposal. In my opinion, I
> think we need to make the unified-props draft minimal so that we can push
> it to WGLC asap. So except for those entity domains which has been defined
> in the existing RFCs (i.e. 'ipv4', 'ipv6', 'pid'), we should not introduce
> more entity domains into this draft. Base on this principle, we also
> suggest moving "ane" domain out of the current unified-prop draft.
>
>
>
> And after the unified-prop draft is pushed to WGLC and published as RFC,
> we can be comfortable with registering a bunch of practical entity domains
> and properties (e.g. cellular addresses, cdni capabilities, ane, etc.) by
> starting a new draft.
>
>
>
> But before that, there is a major issue we need to fix. Just like what I
> posted in the previous email, we need to figure out the consistency issue
> between ALTO Address Type Registry and ALTO Entity Domain Registry. Whether
> we add cellular addresses as a new entity domain or not, this issue has to
> be fixed. Do you agree on this?
>
>
>
> btw. Sabine, would you like to be a co-author of the unified-props draft?
>
>
>
> Best,
>
> Jensen
>
>
>
> On Tue, Feb 27, 2018 at 4:25 PM Dawn Chan <dawn_chen_f@hotmail.com> wrote:
>
> Hi Sabine,
>
>
>
> Actually I do find the proposal of the entity domain “ecgi”, but I do not
> see the detailed definition in
> https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01.
> Actually, since the concept of unified property is clean enough. And I
> still remember that Shawn proposed to add a new domain country code for
> CDNI. So the suggestion is to remove the whole  "Section 3.4 ANE Domain" in
> the unified property map, so that it will be defined in the path vector
> draft itself. This way, other entity domains can be registered in their own
> related document?
>
>
>
> Dawn
>
>
>
> On 27 Feb 2018, at 12:18 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
> <sabine.randriamasy@nokia-bell-labs.com> wrote:
>
>
>
> Hi Richard,
>
>
>
> I agree, the Unified Property draft is definitely a good placeholder for
> the cellular addresses. Domain and entities are already defined in
> https://tools.ietf.org/html/draft-randriamasy-alto-cellular-adresses-01 .
> So how about in a next step, we consider pouring the content of the latter
> draft in the UP draft and in a further step propose a list of properties,
> while looking at other WG to see whether they already specified any?
>
>
>
> Sabine
>
>
>
> *From:* yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com
> <yang.r.yang@gmail.com>] *On Behalf Of *Y. Richard Yang
> *Sent:* Friday, February 23, 2018 8:11 PM
> *To:* Dawn Chan <dawn_chen_f@hotmail.com>
> *Cc:* Gurbani, Vijay (Nokia - US/Naperville) <vijay.gurbani@nokia.com>om>;
> Wendy Roome <wendy@wdroome.com>om>; Randriamasy, Sabine (Nokia -
> FR/Paris-Saclay) <sabine.randriamasy@nokia-bell-labs.com>om>; alto@ietf.org
> *Subject:* Re: unified-props, cellular addresses and path-vector
>
>
>
> It looks that the suggestion by Dawn is reasonable.
>
>
>
> I am taking a look again at the possibility of integrating cellular into
> UP quickly. An alternative is that we get it done shortly, in the next
> couple days.
>
>
>
> If this is the approach, Sabine is a great person to work together. Make
> sense, Sabine?
>
>
>
> Richard
>
>
>
>
>
> On Fri, Feb 23, 2018 at 1:31 AM, Dawn Chan <dawn_chen_f@hotmail.com>
> wrote:
>
> Hi all,
>
>
>
> Draft Unified Property is quite stable at the moment, and the major
> problem left is whether the cellular address needs to be appended.
> Actually, since the Unified Property maintains an entity domain registry to
> achieve extensibility so that we suggest the new entity domain cellular
> address to be registered in the
> https://www.ietf.org/id/draft-randriamasy-alto-cellular-adresses-01.txt itself.
> This way, the draft Unified Property can proceed first.
>
>
>
> Besides, path-vector and unified property depend on each other so they
> should move as a bundle.
>
>
>
> Do you think this is a feasible solution?
>
>
>
> On 23 Feb 2018, at 3:16 AM, Vijay K. Gurbani <vijay.gurbani@nokia.com>
> wrote:
>
>
>
> All: In preparation for moving the unified property draft [0] ahead, the
> minutes of the December 2017 Virtual Interim Meeting [1] indicate that
> the chairs seek answers to the following questions from the WG:
>
> (1) Are cellular addresses an important abstraction that the working
> group will like to introduce in ALTO?  Currently, cellular address
> format is specified in a companion draft [2].
>
> (2) If yes, is the unified-props-new draft the correct place to add the
> cellular representation?
>
> Please note that the unified property draft [0] gates path-vector [3],
> as there is a dependency of path-vector on unified-props.  Thus, the
> plan is to move these two drafts ahead as a bundle.
>
> Which means that we need to reach a conclusion on the questions posed
> above so unified-props and path-vector can move ahead.
>
> Please express an substantive opinion on the above questions in the
> mailing list.
>
> [0] https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
> [1]
>
> https://datatracker.ietf.org/meeting/interim-2017-alto-01/materials/minutes-interim-2017-alto-01-201712180600/
> [2]
> https://datatracker.ietf.org/doc/draft-randriamasy-alto-cellular-adresses/
> [3] https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>
> Thank you,
>
> - vijay
> --
> Vijay K. Gurbani / vijay.gurbani@nokia.com
> Network Data Science, Nokia Networks
> Calendar: http://goo.gl/x3Ogq
>
>
>
>
>
>
>
> --
>
> --
>
>  =====================================
>
> | Y. Richard Yang <yry@cs.yale.edu>   |
>
> | Professor of Computer Science       |
>
> | http://www.cs.yale.edu/~yry/        |
>
>  =====================================
>
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>