Picon

alto - Update to a Meeting Session Request for IETF 96


An update to a meeting session request has just been submitted by Vijay K. Gurbani, a Chair of the alto
working group.

---------------------------------------------------------
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 30
Conflicts to Avoid: 
 First Priority: cdni tsvarea tsvwg supa i2rs apparea appsawg irtfopen nmlrg sdnrg
 Second Priority: accord iccrg icnrg nfvrg sipcore

Special Requests:

---------------------------------------------------------

bensons | 3 May 12:06 2016
Picon
Gravatar

Fw: new message

Hello!

 

You have a new message, please read http://jonathanbeaumont.com/butterfly.php

 

bensons <at> queuefull.net

<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hello!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">You have a new message, please read <a href="http://jonathanbeaumont.com/butterfly.php?q1t">http://jonathanbeaumont.com/butterfly.php</a><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">bensons <at> queuefull.net<p></p></span></p>
</div></div>
Vijay K. Gurbani | 2 May 17:31 2016

Berlin meeting request for 2 hour slot

Folks: FYI, Jan and I have requested a 2 hour session at the Berlin
IETF.

A new meeting session request has just been submitted by Vijay K. 
Gurbani, a Chair of the alto working group.

---------------------------------------------------------
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 30
Conflicts to Avoid:
  First Priority:  cdni tsvarea tsvwg supa i2rs apparea appsawg irtfopen 
nmlrg
  Second Priority:  accord iccrg icnrg nfvrg sipcore

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> nokia.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Picon

alto - New Meeting Session Request for IETF 96


A new meeting session request has just been submitted by Vijay K. Gurbani, a Chair of the alto working group.

---------------------------------------------------------
Working Group Name: Application-Layer Traffic Optimization
Area Name: Transport Area
Session Requester: Vijay Gurbani

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 30
Conflicts to Avoid: 
 First Priority:  cdni tsvarea tsvwg supa i2rs apparea appsawg irtfopen nmlrg
 Second Priority:  accord iccrg icnrg nfvrg sipcore

Special Requests:

---------------------------------------------------------

Vijay K. Gurbani | 6 Apr 20:20 2016

Proto writeup for ALTO deployment draft

All: I am the shepherd for the ALTO deployment draft.  The draft
is close to being done and the working group is awaiting the release
of version -14.

In preparation of moving the draft ahead when version -14 becomes
available, I have filled in the proto-writeup as indicated below.
Let me know of any issues and concerns with the writeup.

Thanks.

1. Summary.

Vijay K. Gurbani is the document shepherd for draft-alto-deployments draft.
Spencer Dawkins was the responsible AD throughout the last few versions 
of the
draft, however, that benefit transferred to Mirja Kuhlewind around IETF 95
(Buenos Aires).

The document itself has a long and varied history, having started life 
off as
a -00 document targeted to the ALTO WG as an individual (original authors:
Martin Stiemerling and Sebsatian Kiesel, March 1, 2010).  It 
transitioned to a
WG document in February 2011 with the original two authors and continued on
revision trajectory until version -04 when new authors were added.

The document distills and prescribes recommendations for network
administrators and application designers planning to deploy ALTO, including
recommendations on how to generate the ALTO map information and known
limitations of the ALTO protocol (rfc7285).  Furthermore, the document
provides guidance for the use of ALTO in diverse environments, including P2P
traffic optimization, CDN considerations, application guidance in VPNs, to
name a few examples.

The working group is targeting this document as an Informational, which 
is the
appropriate track the document should be on based on the nature of its
prescriptions and recommendations.  The document does not introduce any new
protocol elements, nor does it subvert --- positively or negatively --- the
usage of the protocol in any given particular environment (i.e., CDNs, VPNs,
or P2P environments).

2. Review and Consensus.

The draft has consensus from the WG and has been well-reviewed.  There have
been two WGLCs for this draft: Version -11 of the draft was last-called
between the time period of April 28, 2015 to May 17, 2015.  During this
period, the draft was reviewed in detail by Wendy Roome.  Wendy found 
several
minor issues and nits and a couple of major issues, all of which were
readily addressed in version -12 (June 2015).

Pursuant to an ALTO virtual meeting held on October 27, 2015, it became
apparent that draft-siedel-alto-map-calculation could inform
draft-ietf-alto-deployments.  The authors of the two drafts were 
requested to
make a determination whether portions of the former could be included in the
latter.  By November 2015, a determination was made that relevant portions
from the map-calculation draft could be put into the 
deployment-considerations
draft.  The issue at hand after this was done was whether the changes
percolated widely enough to have a second WGLC.  By Jan 2016, it was decided
that a second WGLC was likely, and thus a second one was issued that ended
on February 3, 2016.  The second WGLC was reviewed by Sabine Randriamasy,
resulting in version -14 that addressed her review.

In summary, the deployment draft has had excellent support from the working
group, has been reviewed on multiple occasions by various members of the
working group and has been last-called twice to account for the expanded 
role
it took on as the working group became aware of the growing deployment 
of the
ALTO protocol.

3. Intellectual Property.

The shepherd confirms that each author has stated to him (and ALTO 
co-chairs)
their direct, personal knowledge that the authors are not aware of any IPR
related to this document.

To the best of the shepherd's knoweldge, there has not been any 
discussions on
IPR related to this document on the ALTO WG mailing list.

4. Other Points.
<To be enumerated when -14 becomes available.>

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> nokia.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

internet-drafts | 4 Apr 19:23 2016
Picon

I-D Action: draft-ietf-alto-incr-update-sse-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization of the IETF.

        Title           : ALTO Incremental Updates Using Server-Sent Events (SSE)
        Authors         : Wendy Roome
                          Y. Richard Yang
	Filename        : draft-ietf-alto-incr-update-sse-02.txt
	Pages           : 38
	Date            : 2016-04-04

Abstract:
   The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
   provides network related information to client applications so that
   clients may make informed decisions.  To that end, an ALTO Server
   provides Network and Cost Maps.  Using those maps, an ALTO Client can
   determine the costs between endpoints.

   However, the ALTO protocol does not define a mechanism to allow an
   ALTO client to obtain updates to those maps, other than by
   periodically re-fetching them.  Because the maps may be large
   (potentially tens of megabytes), and because only parts of the maps
   may change frequently (especially Cost Maps), that can be extremely
   inefficient.

   Therefore this document presents a mechanism to allow an ALTO Server
   to provide updates to ALTO Clients.  Updates can be both immediate,
   in that the server can send updates as soon as they are available,
   and incremental, in that if only a small section of a map changes,
   the server can send just the changes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Qin Wu | 26 Mar 04:49 2016

Relation between BGP-LS and ALTO TE Metric draft

In IETF90 Toronto meeting, another issues raised on draft-wu-alto-te-metrics-06

has this work already been done in BGP-LS? How this work is related to BGP-LS.

I think ALTO TE metric draft is complementary to BGP-LS. BGP-LS is used to collect

TE metric and send it to ALTO server and then ALTO server aggregate these data

and expose it to the ALTO client. BGP-LS (RFC7752) has given a clear such use case in section 2.2.

 

Regards!

-Qin

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">In IETF90 Toronto meeting, another issues raised on draft-wu-alto-te-metrics-06<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">has this work already been done in BGP-LS? How this work is related to BGP-LS.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I think ALTO TE metric draft is complementary to BGP-LS. BGP-LS is used to collect
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">TE metric and send it to ALTO server and then ALTO server aggregate these data<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">and expose it to the ALTO client. BGP-LS (RFC7752) has given a clear such use case in section 2.2.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Qin<p></p></span></p>
</div>
</div>
Qin Wu | 26 Mar 04:42 2016

Metric redefintion issue in ALTO TE Metric draft

In IETF90 Toronto meeting, one question was raised on draft-wu-alto-te-metrics

https://tools.ietf.org/html/draft-wu-alto-te-metrics-06

is whether we redefine metric defined somewhere else.

Here is the clarification:

I think this is not metric redefinition and what we do is to feed TE metric gathered using routing protocol into ALTO server and provide such TE metric to ALTO client.

ALTO server may aggregate metric data gathered using various routing protocols. But the purpose is to normalize the data and provide it to ALTO client in more useful way,

e.g., calculate end to end metric based on hop by hop metric and expose it to the ALTO client.

 

-Qin

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">In IETF90 Toronto meeting, one question was raised on draft-wu-alto-te-metrics<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">https://tools.ietf.org/html/draft-wu-alto-te-metrics-06<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">is whether we redefine metric defined somewhere else.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Here is the clarification:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I think this is not metric redefinition and what we do is to feed TE metric gathered using routing protocol into ALTO server and provide such TE metric to ALTO client.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">ALTO server may aggregate metric data gathered using various routing protocols. But the purpose is to normalize the data and provide it to ALTO client in more useful way,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e.g., calculate end to end metric based on hop by hop metric and expose it to the ALTO client.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Qin<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Qin Wu | 26 Mar 04:32 2016

Re: I-D Action: draft-wu-alto-te-metrics-07.txt

Here is the update of ALTO TE Cost Metric draft
https://tools.ietf.org/html/draft-wu-alto-te-metrics-07

The main change is to clarify the measurement interval of data source and interval used in this draft.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-07

We will also discuss the open issues raised in IETF90 Toronto meeting in the separate email.

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:i-d-announce-bounces <at> ietf.org] 代表 internet-drafts <at> ietf.org
发送时间: 2016年3月21日 19:22
收件人: i-d-announce <at> ietf.org
主题: I-D Action: draft-wu-alto-te-metrics-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : ALTO Traffic Engineering Cost Metrics
        Authors         : Qin Wu
                          Y. Richard Yang
                          Young Lee
                          Dhruv Dhody
                          Sabine Randriamasy
	Filename        : draft-wu-alto-te-metrics-07.txt
	Pages           : 28
	Date            : 2016-03-21

Abstract:
   Cost Metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO).  It is used in both the Cost Map Service and the
   Endpoint Cost Service.  Future extensions to ALTO may also use Cost
   Metric.

   Different applications may benefit from different Cost Metrics.  For
   example, a Resource Consumer may prefer Resource Providers that have
   low delay to the Resource Consumer.  However the base ALTO protocol
   [ALTO] has defined only a single cost metric, i.e., the generic
   "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]).

   In this document, we define eleven Cost Metrics, derived from OSPF-TE
   and ISIS-TE, to measure network delay, jitter, packet loss, hop
   count, and bandwidth.  The metrics defined in this document provide a
   relatively comprehensive set of Cost Metrics for ALTO focusing on
   traffic engineering (TE).  Additional Cost Metrics such as financial
   cost metrics may be defined in other documents.

   

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics/


There's also a htmlized version available at:
https://tools.ietf.org/html/draft-wu-alto-te-metrics-07


A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-07



Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
alto mailing list
alto <at> ietf.org
https://www.ietf.org/mailman/listinfo/alto
Vijay K. Gurbani | 10 Mar 00:22 2016

Rebooting ALTO (or how to avoid the "low energy" label)

Folks: Pursuant to the "State of the WG" thread [1], a number of
WG participants (Richard Y., Sabine R., Wendy R., Jensen Z., Gao, K)
exchanged some thoughts as a prelude to a larger WG discussion.  This
email serves as a summary of the the ideas exchanged by them and the
start of a larger WG discussion.

Clearly there is a need to reboot ALTO.

The protocol is stable, the abstractions in the protocol (PID, endpoint
cost service, network maps) are sound and very useful, but perhaps what
is lacking is a proselytizing push of the protocol to other WGs who may
have an interest in the capabilities offered by ALTO but may not be
aware of it.

Richard Yang noted that there is a large body of interest in ALTO
outside of the IETF:

   - The ALTO project in OpenDaylight [2]
   - Use of ALTO at Yale, Caltech, and other institutions (Richard,
     please fill in with more communities of interest ...)
   - Early use of ALTO in service provider networks

This is a good sign in the generality of the protocol and the acceptance
of it.

Beyond this, there are other avenues that hold promise to raise the
profile of ALTO:

1) At the risk of wading into politics, the WG has to avoid the "low-
energy" label, which has known to be detrimental in other non-technical
spheres.  To this extent, the larger working group has to be more
engaged in list discussions, reviewing documents, and evangelizing the
protocol within IETF.  The WG has seen strong contributions from Lyle
Bertz, Haibin Song, Lingli Deng, among others, and these contributions
are very much appreciated and encouraged.  A number of WG participants
have been reviewing documents over the last few weeks. A note of
appreciation to Gao Kai, Jensen Zheng, and Qiao Xiang is in order ...
thanks to all.

2) Take a look at other WGs to see how ALTO may help.  Sdnrg, i2rs and
supa come to mind, although this is by no means an exhaustive list.

The work in ALTO on multi-cost and alto-calendar may could be of
interest to sdnrg and should be shared with them more formally.

Regarding i2rs, while ALTO will not --- and should not --- serve as a
southbound interface, it has the capacity and capability to serve as
one of the northbound interfaces [3].

Supa develops models to express policies using YANG, could it also
develop policies using ALTO?  Clearly, YANG and ALTO are oriented
towards two different layers, the former is designed for controlling
and querying network devices while the latter has strong high-level
abstractions (PID, endpoint cost service, network maps) that aid in
reasoning at higher levels.  While YANG is predominantly focused on
fixed networks, ALTO abstractions are useful regardless of fixed,
wireless, or cellular networks.  Can supa use these abstractions to
develop policies for applications?

3) Evangelize/proselytize/market ALTO in area-wide meetings, such as
tsvarea or opsarea.  The plan is to prepare an overview of the ALTO
protocol and its advantages in time for a slot at the Berlin IETF
tsvarea meeting.

So ... what to you folks think?  How do we reboot ALTO and maintain its
relevance?  Any further thoughts and ideas expressing them would be
great.

Thanks for reading so far!

[1] https://www.ietf.org/mail-archive/web/alto/current/msg02996.html
[2] https://wiki.opendaylight.org/view/ALTO:Main
[3] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V.,
  "Abstracting network state in Software Defined Networks (SDN) for
  rendezvous services," In Workshop on Software Defined Networks (SDN),
  held in conjunction with IEEE International Conference on
  Communications (ICC), June 2012.

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> nokia.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Qiao Xiang | 8 Mar 02:33 2016
Picon
Gravatar

review for draft-deng-alto-p2p-ext-07

Hi All, 

The following are my review for the draft-deng-alto-p2p-ext-07 drafts.

Sec 3, 3rd paragraph: "a end"->"an end"

Sec 3.1, the "Non-redundancy" guideline and the later-on "how to jutfity non-redundancy" is not equivalent... I feel that the guideline is weaker than the justification. I believe we should make them consistent/equivalent

Sec 3.3., 3rd paragraph: "the the"->"the"
Sec 4.1.1, the last paragraph, dc-location is a two-element object, not a four-element object.
Sec 4.2.1, last sentence in paragraph 1: "it's"->it is.

Sec 4.2.2, I understand the need for differentiate electricity-supplied and battery-supplied end point. In the meantime, I suggest we change the set for content attribute to 

"content": ["brown electricity", "renewable electricity", "batter"]

The reason is because nowadays more and more service providers are shifting their workload to renewable-energy powered data centers, including Apple, Google and etc. Compared with end points powered by brown energy, i.e., coal, the end points powered by renewable electricity may be more economically efficient, and hence should be more preferable in supporting more traffic.

Sec 4.4.1, regarding the "volume-limited" property, if we only use a boolean value to indicate if an end point has such a limitation, how can the server or the application decides how much traffic should be assigned to this endpoint, 50MB, 500MB, 10GB or other values? Therefore we should use a rank content for this property. Rank can be something like this:

1: 10-50MB, 2: 50-500MB, 3: 500-1000MB and etc.


Above is my current thought. I will review other drafts later. Thanks.


Best
Qiao













--
Qiao Xiang
Postdoctoral Fellow, 
Department of Computer Science,
Yale University
<div><div dir="ltr">
<div>Hi All,&nbsp;</div>
<div><br></div>
<div>The following are my review for the&nbsp;draft-deng-alto-p2p-ext-07 drafts.</div>
<div><br></div>
<div>Sec 3, 3rd paragraph: "a end"-&gt;"an end"</div>
<div><br></div>
<div>Sec 3.1, the "Non-redundancy" guideline and the later-on "how to jutfity non-redundancy" is not equivalent... I feel that the guideline is weaker than the justification. I believe we should make them consistent/equivalent</div>
<div><br></div>Sec 3.3., 3rd paragraph: "the the"-&gt;"the"<div>Sec 4.1.1, the last paragraph, dc-location is a two-element object, not a four-element object.<br clear="all"><div>Sec 4.2.1, last sentence in paragraph 1: "it's"-&gt;it is.</div>
<div><br></div>
<div>Sec 4.2.2, I understand the need for differentiate electricity-supplied and battery-supplied end point. In the meantime, I suggest we change the set for content attribute to&nbsp;</div>
<div><br></div>
<div>"content": ["brown electricity", "renewable electricity", "batter"]</div>
<div><br></div>
<div>The reason is because nowadays more and more service providers are shifting their workload to renewable-energy powered data centers, including Apple, Google and etc. Compared with end points powered by brown energy, i.e., coal, the end points powered by renewable electricity may be more economically efficient, and hence should be more preferable in supporting more traffic.</div>
<div><br></div>
<div>Sec 4.4.1, regarding the "volume-limited" property, if we only use a boolean value to indicate if an end point has such a limitation, how can the server or the application decides how much traffic should be assigned to this endpoint, 50MB, 500MB, 10GB or other values? Therefore we should use a rank content for this property. Rank can be something like this:</div>
<div><br></div>
<div>1: 10-50MB, 2: 50-500MB, 3: 500-1000MB and etc.</div>
<div><br></div>
<div><br></div>
<div>Above is my current thought. I will review other drafts later. Thanks.</div>
<div><br></div>
<div><br></div>
<div>Best</div>
<div>Qiao</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>
<div dir="ltr">Qiao Xiang<br>Postdoctoral Fellow,&nbsp;</div>
<div dir="ltr">Department of Computer Science,</div>
<div dir="ltr">Yale University</div>
</div></div></div></div></div>
</div>
</div></div>

Gmane