Re: [alto] extension questions and comments

"Y. Richard Yang" <yry@cs.yale.edu> Tue, 29 October 2013 03:50 UTC

Return-Path: <yang.r.yang@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 B38FD11E819C for <alto@ietfa.amsl.com>; Mon, 28 Oct 2013 20:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.982
X-Spam-Level:
X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_OBFU_PART_OVE=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKE-jZYr8UtI for <alto@ietfa.amsl.com>; Mon, 28 Oct 2013 20:50:11 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA321F9FCF for <alto@ietf.org>; Mon, 28 Oct 2013 20:50:08 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb1so8210996pad.31 for <alto@ietf.org>; Mon, 28 Oct 2013 20:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U/LMO045J96vFxA2Mh/fpDbxSKv3r2ZksUJaheWSQUo=; b=GoLDBKbyfnzJOZL+rNSeGtky6lxmXfBATGtknJUjdrISLlgr3a0yaxS7JaVixXFovi T02ZuoEGWN4lO69E1t9S6CEkMrpc7ratLeX/KXBdem9gzW67sjWBOAmF0ddMrvqsAJ1H 8hzKgnr8BTg+kVgiOVDmXSnSiRYwrwKmigXXplJp02Nne8WBFbGM4BRdX5deks8q2R2M XeR4IjC3SMzmSf6eKdmDtCx7XfPPEqKLeElBpZfk2yHJJ6HX7FzIRmXe6Dq9U1zjKrRD xl0Bkn1ERyVQH9rC0I7KvaaYY5RimsJZ2hzaMjg16MxRsrfGPn9RVEf+iU0WKexF3Rr+ wsEQ==
MIME-Version: 1.0
X-Received: by 10.68.202.38 with SMTP id kf6mr24879681pbc.43.1383018608571; Mon, 28 Oct 2013 20:50:08 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.68.47.195 with HTTP; Mon, 28 Oct 2013 20:50:08 -0700 (PDT)
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B740087@xmb-rcd-x04.cisco.com>
References: <526EA379.308@grotto-networking.com> <45A697A8FFD7CF48BCF2BE7E106F06040B740087@xmb-rcd-x04.cisco.com>
Date: Mon, 28 Oct 2013 23:50:08 -0400
X-Google-Sender-Auth: 2j1cBJajcxn9SWkgsDsgpPe2vAg
Message-ID: <CANUuoLr-OM3xBnONe9tx2WKB8QjV_oH4Vq5ghBidhauUQnq_Hw@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b15aef9e1be1904e9d91c68"
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] extension questions and comments
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 29 Oct 2013 03:50:12 -0000

On Mon, Oct 28, 2013 at 1:54 PM, Reinaldo Penno (repenno) <repenno@cisco.com
> wrote:

>  I also think seedorf-lmap is a very interesting draft.
>
>
Share the opinion. It is quite interesting indeed! At a first quick look,
it defines another set of metrics (
http://data.fcc.gov/download/measuring-broadband-america/2013/Technical-Appendix-feb-2013.pdfPage
26, which the te-metrics doc may need to look into as well).

It looks like that the draft is still evolving. I can see several
possibilities in defining network maps: one is the geo-location already
well defined in the draft; Table 5 of the Technical-Appendix-feb-2013.pdf
suggests that many maps can be constructed. This is interesting and also
shows that we will need to think more on how to handle a wealth of such
information. Good work!


>  But what I'm most interested in a way to make maps writable.  I want an
> app to be be able to write to a map therefore influencing its own cost and
> attributes.
>

In the particular fcc MBA context, a concrete example is to change the
subscriber tier (end point property). But since you mentioned map, I guess
you are saying e2e (e.g.,  more narrowly bounded app flow). In addition to
flow meta data, Lingli pointed out OneAPI in the context of mobile devices
as another related work:
http://www.gsma.com/oneapi/faq/restful-api-specifications

Richard


>
>   From: Greg Bernstein <gregb@grotto-networking.com>
> Date: Monday, October 28, 2013 10:48 AM
> To: "alto@ietf.org" <alto@ietf.org>
> Subject: [alto] extension questions and comments
>
>   Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( ,
> here are some questions/comments.
> These comments/questions are from the perspective of creating an ALTO
> topology service (suitable for large bandwidth and SDN applications).
> http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01 ALTO for
> VPNs: Way back when we started talking about "topology" like extensions.
> The concept of ALTO for "controlled or partially controlled" environments
> was floated. It seems that a VPN type of service would be the exemplar of
> such an environment and hence pave the way for "restricted environment" use
> of ALTO.  *Questions*: * Are there specific additions to the REST API to
> offer this some kind of security, i.e., to keep others from gaining
> information about a customers VPN? Or would a general approach to security
> of this interface be specified?*
> http://tools.ietf.org/html/draft-song-alto-overlay-routing-00
> Extensions for Multiple path choices: In our large bandwidth work we
> considered both path representations as well as graph representations. This
> proposal would extend ALTO by reporting costs on multiple possible paths
> between a source and destination. Hence could also work for the large
> bandwidth case with appropriate extensions.  Both in this draft and the VPN
> draft, we may have the situation where the client uses ALTO information to
> not only make a choice but then relay that choice back to the network via
> some type of "reservation interface".
> http://tools.ietf.org/html/draft-wu-alto-te-metrics-00Defines costs
> metrics based on OSPF-TE. We would need for such metrics for the "general"
> topology service.
> http://tools.ietf.org/html/draft-roome-alto-pid-properties-00PID
> properties -- *Comments*: This is a step on the way to a "NID" that we
> would use in a graph topology (multi-switch) representation, i.e., where
> we'd define a Node with Id and properties.
> http://tools.ietf.org/html/draft-seedorf-lmap-alto-02,
> http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00Very interesting
> applications. Any interest from the authors of these drafts in
> bandwidth/topology type information?
>
> Best Regards
>
> Greg B.
>
>
> On 10/22/2013 1:02 PM, Vijay K. Gurbani wrote:
>
> Folks: As you prepare slides, etc. for your ALTO extensions, please
> consult the latest institutional memory on how to taxonomize or classify
> the extensions; this was captured rather succinctly and successfully
> during the Berlin IETF side meeting [1].
>
> Enrico and I will be looking to see how we can group the various
> extensions under this ontology.  It will make it tractable to understand
> and appreciate the extensions as we grapple with them.
>
> Thanks,
>
> [1] http://www.ietf.org/proceedings/87/minutes/minutes-87-alto#ad-hoc
>
> - vijay
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>


-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================