Gao Kai | 2 Jul 06:26 2015
Picon

Protocol between alto server and information sources

Hi all,

I have some thoughts on the implementation of ALTO servers and I'd like to get some feedback on the idea.

The basic functionalities of an ALTO server are:

- Collecting data from the information sources;
- Publishing the information to clients (using ALTO protocol).

While the latter is well-defined in RFC 7285, there are no standards for the communication between an ALTO server and information sources.  There are three scenarios:

- The ALTO server is deeply embedded into the information source, just like what we are trying to do in Open Daylight.

- The ALTO server is partially embedded into the information source.  For example, in the early stage of out implementation in ODL, we used an external server which pulls data from ODL using RESTCONF and converts them into RFC7285-compatible formats.

- The ALTO server is decoupled from the information source.

It is for the last scenario that a standard protocol might be helpful.  To get started, I can think of two basic and probably most common implementation choices, and they both can have multiple different information sources:

- End-to-End:
  The server builds its maps using an full-mesh internal representation.  This can happen if the server is using end-to-end measurement methods or it just doesn't have the priority to fetch topology information.

- Topology-based:
  In this case the server is using a graph representation and there can be some internal nodes besides endpoints.  A server can fetch topology view directly, either from configurations or by making a query to a SDN controller.  Also one can use aggregated data such as the inferred AS graph.

Accordingly we can identify the following kinds of information for both implementation choices:

- Connection-based statistics;
- Link-based statistics;
- (?) Node-based statistics.

All three statistics can be encapsulated using the following JSON representation:

    {
        /* the type of the statistics */
        'type': 'alto-IS-e2e',
        /* choices: alto-IS-e2e, alto-IS-link, alto-IS-node, etc. */

        /* identity for the provider of the information */
        'source': 'grid-ftp-client:ef423dab',

        'data': [
            {
                'meta': {
                    /* e2e */
                    'src': 'ipv4:X.X.X.X',
                    'dst': 'ipv4:Y.Y.Y.Y',

                    /* link */
                    'id': 'e15',

                    /* node */
                    'id': 'n02'
                },
                'statistics': [
                    /* e2e */
                    'average-round-trip-time': '10ms',
                    'average-drop-rate-percentage': '5',
                    ...,

                    /* link */
                    'status': 'up',
                    'capacity': '10Gbps',
                    'available-bandwidth': '5Gbps',
                    ...,

                    /* node */
                    ...
                    /* actually I don't have any statistics for nodes in mind */
                ]
            },
            ...
        ]
    }

There are also considerations on push/pull modes, integration to IRD and potential DDoS threats but I'd like to hear some feedback on the proposal from you alto guys.

Thanks!

Regards,
Kai
<div>
    Hi all,<br><br>
      I have some thoughts on the implementation of ALTO servers and I'd
      like to get some feedback on the idea.<br><br>
      The basic functionalities of an ALTO server are:<br><br>
      - Collecting data from the information sources;<br>
      - Publishing the information to clients (using ALTO protocol).<br><br>
      While the latter is well-defined in RFC 7285, there are no
      standards for the communication between an ALTO server and
      information sources.&nbsp; There are three scenarios:<br><br>
      - The ALTO server is deeply embedded into the information source,
      just like what we are trying to do in Open Daylight.<br><br>
      - The ALTO server is partially embedded into the information
      source.&nbsp; For example, in the early stage of out implementation in
      ODL, we used an external server which pulls data from ODL using
      RESTCONF and converts them into RFC7285-compatible formats.<br><br>
      - The ALTO server is decoupled from the information source.<br><br>
      It is for the last scenario that a standard protocol might be
      helpful.&nbsp; To get started, I can think of two basic and probably
      most common implementation choices, and they both can have
      multiple different information sources:<br><br>
      - End-to-End:<br>
      &nbsp; The server builds its maps using an full-mesh internal
      representation.&nbsp; This can happen if the server is using end-to-end
      measurement methods or it just doesn't have the priority to fetch
      topology information.<br><br>
      - Topology-based:<br>
      &nbsp; In this case the server is using a graph representation and
      there can be some internal nodes besides endpoints.&nbsp; A server can
      fetch topology view directly, either from configurations or by
      making a query to a SDN controller.&nbsp; Also one can use aggregated
      data such as the inferred AS graph.<br><br>
      Accordingly we can identify the following kinds of information for
      both implementation choices:<br><br>
      - Connection-based statistics;<br>
      - Link-based statistics;<br>
      - (?) Node-based statistics.<br><br>
      All three statistics can be encapsulated using the following JSON
      representation:<br><br>
      &nbsp;&nbsp;&nbsp; {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* the type of the statistics */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'type': 'alto-IS-e2e',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* choices: alto-IS-e2e, alto-IS-link, alto-IS-node, etc.
      */<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* identity for the provider of the information */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'source': 'grid-ftp-client:ef423dab',<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'data': [<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'meta': {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* e2e */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'src': 'ipv4:X.X.X.X',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'dst': 'ipv4:Y.Y.Y.Y',<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* link */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'id': 'e15',<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* node */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'id': 'n02'<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; },<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'statistics': [<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* e2e */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'average-round-trip-time': '10ms',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'average-drop-rate-percentage': '5',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...,<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* link */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'status': 'up',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'capacity': '10Gbps',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 'available-bandwidth': '5Gbps',<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...,<br><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* node */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* actually I don't have any statistics for
      nodes in mind */<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ]<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; },<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ]<br>
      &nbsp;&nbsp;&nbsp; }<br><br>
      There are also considerations on push/pull modes, integration to
      IRD and potential DDoS threats but I'd like to hear some feedback
      on the proposal from you alto guys.<br><br>
      Thanks!<br><br>
      Regards,<br>
      Kai<br>
  </div>
Y. Richard Yang | 30 Jun 00:54 2015
Picon

A generalization of ALTO abstract path vector

Dear all,

Some of us worked on a more general foundation for the abstract path vector design. In particular, we studied a more general problem called routing state abstraction, and proposed a more general framework called routing state abstraction based on declarative equivalence. We plan to write up a draft to discuss the more general design at IETF 93. More info on the paper is below. Any comments or feedback will be greatly appreciated!

Richard

====
Title: Routing-State Abstraction Based on Declarative Equivalence

Abstract: Providing abstract views on top of raw network state can provide substantial benefits to both the network OS, who manages the network state, and the network control applications, who consume the network state. In this paper, we conduct the first study to provide control applications with access to the routing state, which is a key component of the network state. We design a simple, efficient algorithm to look up a route query in a flow rule manager (FRM), which is a common data structure storing a network's routing state. More importantly, we design a simple, novel interface based on a principle called declarative equivalence for network control applications to query the routing state, and the network OS uses redundancy elimination to compute equivalent, but minimal routing state, providing the first, novel, systematic algorithm to compute abstract, compressed routing state. We implement our design in OpenDaylight and show substantial performance benefits.

<div><div dir="ltr">Dear all,
<div><br></div>
<div>Some of us worked on a more general foundation for the abstract path vector design. In particular, we studied a more general problem called routing state abstraction, and proposed a more general framework called routing state abstraction based on declarative equivalence. We plan to write up a draft to discuss the more general design at IETF 93. More info on the paper is below. Any comments or feedback will be greatly appreciated!</div>
<div><br></div>
<div>Richard<br><br>
</div>
<div>====</div>
<div>Title:&nbsp;Routing-State Abstraction Based on Declarative Equivalence<br><br>
</div>
<div><div>Abstract: Providing abstract views on top of raw network state can provide substantial benefits to both the network OS, who manages the network state, and the network control applications, who consume the network state. In this paper, we conduct the first study to provide control applications with access to the routing state, which is a key component of the network state. We design a simple, efficient algorithm to look up a route query in a flow rule manager (FRM), which is a common data structure storing a network's routing state. More importantly, we design a simple, novel interface based on a principle called declarative equivalence for network control applications to query the routing state, and the network OS uses redundancy elimination to compute equivalent, but minimal routing state, providing the first, novel, systematic algorithm to compute abstract, compressed routing state.&nbsp;We implement our design in OpenDaylight and show substantial performance benefits.</div></div>
<div><br></div>
<div>A link to the paper:&nbsp;<br><a href="http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf">http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf</a><br>
</div>
</div></div>
Jan Seedorf | 29 Jun 16:27 2015
Picon

ALTO Session at IETF-93

The ALTO slot at IETF-93 will be

 

***

    Tuesday, Afternoon Session II 1520-1720

    Room Name: Berlin/Brussels size: 100

***

 

Please note that the agenda may potentially change on short notice.

 

See you all in Prague,

 

-          Jan

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">The ALTO slot at IETF-93 will be<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoPlainText"><span lang="EN-US">***<p></p></span></p>
<p class="MsoPlainText"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Tuesday, Afternoon Session II 1520-1720<p></p></span></p>
<p class="MsoPlainText"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Room Name: Berlin/Brussels size: 100<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">***<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please note that the agenda may potentially change on short notice.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">See you all in Prague,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoListParagraph">
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="mailto:jan.seedorf <at> neclab.eu"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Jan Seedorf | 29 Jun 16:27 2015
Picon

ALTO Interop at IETF-93 in Prague

Dear all,

 

as discussed on this list and requested by several of you, we have arranged a room for an ALTO interop at IETF-93 as follows:

 

** MONDAY, July 20th, 20:00-23:00 **

 

There has already been some good discussion on this list regarding the interop, plus a draft from Wendy. Please continue this discussion, so that we can make the best use of the time in Prague.

 

-          Jan

 

============================================================

Prof. Dr. Jan Seedorf

Senior Researcher

NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.     +49 (0)6221 4342-221

Fax:     +49 (0)6221 4342-155

e-mail:  jan.seedorf <at> neclab.eu

============================================================

NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB, Registered in England 2832014

 

<div>
<div class="WordSection1">
<p class="MsoNormal">Dear all,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span lang="EN-US">as discussed on this list and requested by several of you, we have arranged a room for an ALTO interop at IETF-93 as follows:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">** MONDAY, July 20th, 20:00-23:00 **≤p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">There has already been some good discussion on this list regarding the interop, plus a draft from Wendy. Please continue this discussion, so that we can make the best use of the time in Prague.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoListParagraph">
<span lang="EN-US"><span>-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span lang="EN-US">Jan<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Prof. Dr. Jan Seedorf<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Senior Researcher<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel.&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-221<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fax:&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)6221 4342-155<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">e-mail:&nbsp; </span><a href="mailto:jan.seedorf <at> neclab.eu"><span lang="EN-US">jan.seedorf <at> neclab.eu</span></a><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">============================================================<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End&nbsp; Road, London, HA4 6QE, GB, Registered in England 2832014<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
</div>
Vijay K. Gurbani | 26 Jun 19:50 2015

Agenda requests for Prague IETF 93

Folks: Please send Jan and me your agenda requests for the Prague
IETF by Friday, Jul 3, 2015.

Please include in your email the following:

Name of presenter
Title
Time required
Relevant Drafts

We have received a couple of agenda requests already.

We will post a draft agenda by Monday, Jul 7 2015.

Thank you,

- vijay
--

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

Lingli Deng | 11 Jun 04:19 2015

FW: New Version Notification for draft-deng-alto-p2p-ext-06.txt

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } -->


Date: Thu, 11 Jun 2015 09:19:47 +0800
From: denglingli <at> chinamobile.com
To: lingli.deng <at> outlook.com; lingli.deng <at> 139.com
Subject: Fw:New Version Notification for draft-deng-alto-p2p-ext-06.txt

Hi all,

We posted a new revision for extended endpoint properties, which is updated according to suggestions and comments gathered in Dallas.  
Please refer to the following remarks to the discussion minutes for further clarifications.
Your review and comments would be more than welcome.

Regards,
Lingli

**from alto <at> ietf92 minutes**

draft-deng-alto-p2p-ext-05

JS: should we hold information that changes frequently (like 2G/3G/4G)?

[dll]: 06 version updated and use "cellular" for "2G/3G/4G" instead of "2G", "3G" and "4G", which can be subject to frequent changes.

VG (Vijay Gurbani): How to prevent revealing private information?

[dll]: There is a dedicated section describing the privacy protection mechanism that might be used by ALTO for endpoint property.

In a word, the privacy protection requirement is considered to be an application-specific, property-specific and operator-specific,

which can be addressed by introduction of privacy protection mapping in property definition and policy configuration.

Where the general mechanism for privacy protection

JS: Max bandwidth / best technology for a given endpoint may be more stable.

[dll] Bandwidth related information has been defined as one of the subscription related property "provisioned_bandwidth" in Section 4.4.2.

JS: Who has read a document? 2 hands raised.

RY: Document touches dynamics and privacy.

JS: This topic is returning. According to IESG, ALTO is not for TE and avoiding congestions, information changing within seconds are out of scope. Daily - in scope.

[dll] In the text, it is clearly stated that dynamic congestion related information is out of scope for endpoint properties. However, there is no clear boundary between which is in scope and which is not.

RY: What is too dynamic, what is not?

JS (as indiv.): 3G/4G is too dynamic.

[dll] Changed into cellular in the latest version.

JS: Rich Woundy was always concerned about disclosing business information.

RY: Privacy is a serious issue.

[dll] Privacy is an honoured requirement. General considerations and guidelines are stated in Section 3.3.

And for each property specified afterwards, property-specific privacy considerations are stated respectively.

Take network_access for instance: There is concern about undesirable privacy leakage via network_access properties to distrusted ALTO clients. In such cases, according to the definitions above, either the endpoint itself or the ISP who is running the ALTO server can either specify an access control policy to prevent undesirable exposure to specific ALTO clients or use a privacy preserving mapping from the raw description of access technologies to a number of abstract relative ranking information instead. Moreover, the endpoint or the ISP might choose to use another subscription related property "provisioned_bandwidth" (defined later in Section 4.4.2) instead of "network_access".

SS (Sergey Slovetskiy): What defines what is in scope / out of scope?

JS: ALTO Prolem Statement

SS: Fast-changing properties may be important for CDNs.

[dll]: Would be happy to hear more about this consideration, and let the WG decide if they are suitable to be defined as endpoint properties.




---------
邓灵莉

中国移动通信研究院

denglingli <at> chinamobile.com

<!-- .ExternalClass .ecxgrayEdit { color:#999999; } .ExternalClass .ecxgrayPreEdit { color:#999999; background:#316AC5; } .ExternalClass { } -->----邮件原文----
发件人:internet-drafts <internet-drafts <at> ietf.org>
收件人:Haibin Song <haibin.song <at> huawei.com>,Qin Wu <sunseawq <at> huawei.com>,Wenson Wu <sunseawq <at> huawei.com>,Richard Yang <yry <at> cs.yale.edu>,Haibin Song <haibin.song <at> huawei.com>,Deng Lingli <denglingli <at> chinamobile.com>,Sebastian Kiesel <ietf-alto <at> skiesel.de>,Yang Yang <yry <at> cs.yale.edu>,Lingli Deng <denglingli <at> chinamobile.com>,Sebastian Kiesel <ietf-alto <at> skiesel.de>
抄 送: (无)
发送时间:2015-06-11 09:09:45
主题:New Version Notification for draft-deng-alto-p2p-ext-06.txt


A new version of I-D, draft-deng-alto-p2p-ext-06.txt
has been successfully submitted by Lingli Deng and posted to the
IETF repository.

Name: draft-deng-alto-p2p-ext
Revision: 06
Title: Extended End Point Properties for Application-Layer Traffic Optimization
Document date: 2015-06-10
Group: Individual Submission
Pages: 18
URL: https://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-06.txt
Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
Htmlized: https://tools.ietf.org/html/draft-deng-alto-p2p-ext-06
Diff: https://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-06

Abstract:
 The purpose of the Application-Layer Traffic Optimization (ALTO)
 protocol is to provide better-than-random peer selection for P2P
 networks. The base ALTO protocol focuses, only on providing network
 topological location information (i.e., network maps and cost maps).
 However, the peer selection method of an endpoint may also use other
 properties, such as geographic location. This document defines a
 framework and an extended set of End Point properties (EP properties)
 to extend the base ALTO protocol.

 


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.

The IETF Secretariat


Subject:New Version Notification for draft-deng-alto-p2p-ext-06.txt


A new version of I-D, draft-deng-alto-p2p-ext-06.txt
has been successfully submitted by Lingli Deng and posted to the
IETF repository.

Name: draft-deng-alto-p2p-ext
Revision: 06
Title: Extended End Point Properties for Application-Layer Traffic Optimization
Document date: 2015-06-10
Group: Individual Submission
Pages: 18
URL: https://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-06.txt
Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
Htmlized: https://tools.ietf.org/html/draft-deng-alto-p2p-ext-06
Diff: https://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-06

Abstract:
 The purpose of the Application-Layer Traffic Optimization (ALTO)
 protocol is to provide better-than-random peer selection for P2P
 networks. The base ALTO protocol focuses, only on providing network
 topological location information (i.e., network maps and cost maps).
 However, the peer selection method of an endpoint may also use other
 properties, such as geographic location. This document defines a
 framework and an extended set of End Point properties (EP properties)
 to extend the base ALTO protocol.

 


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.

The IETF Secretariat




<div><div dir="ltr">

&lt;!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--&gt;<div dir="ltr">
<br><br><div>Date: Thu, 11 Jun 2015 09:19:47 +0800<br>From: denglingli <at> chinamobile.com<br>To: lingli.deng <at> outlook.com; lingli.deng <at> 139.com<br>Subject: Fw:New Version Notification for draft-deng-alto-p2p-ext-06.txt<br><br><div>Hi all,</div>
<div><br></div>
<div>We posted a new revision for extended endpoint properties, which is updated according to suggestions and comments gathered in Dallas. &nbsp;</div>
<div>Please refer to the following remarks to the discussion minutes for further clarifications.</div>
<div>Your review and comments would be more than welcome.</div>
<div><br></div>
<div>Regards,</div>
<div>Lingli</div>
<div><br></div>
<div>
<p class="ecxMsoPlainText"><span lang="EN-US">**from alto <at> ietf92 minutes**≤/span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">draft-deng-alto-p2p-ext-05</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: should we hold information that changes frequently (like 2G/3G/4G)?</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll]: 06 version updated and use "cellular" for "2G/3G/4G" instead of "2G", "3G" and "4G", which can be subject to frequent changes.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">VG (Vijay Gurbani): How to prevent revealing private information?</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll]: There is a dedicated section describing the privacy protection mechanism that might be used by ALTO for endpoint property.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">In a word, the privacy protection requirement is considered to be an application-specific, property-specific and operator-specific,</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">which can be addressed by introduction of privacy protection mapping in property definition and policy configuration.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">Where the general mechanism for privacy protection</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: Max bandwidth / best technology for a given endpoint may be more stable.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll] Bandwidth related information has been defined as one of the subscription related property "provisioned_bandwidth" in Section 4.4.2.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: Who has read a document? 2 hands raised.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">RY: Document touches dynamics and privacy.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: This topic is returning. According to IESG, ALTO is not for TE and avoiding congestions, information changing within seconds are out of scope. Daily - in scope.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll] In the text, it is clearly stated that dynamic congestion related information is out of scope for endpoint properties. However, there is no clear boundary between which is in scope and which is not.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">RY: What is too dynamic, what is not?</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS (as indiv.): 3G/4G is too dynamic.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll] Changed into cellular in the latest version.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: Rich Woundy was always concerned about disclosing business information.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">RY: Privacy is a serious issue.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll] Privacy is an honoured requirement. General considerations and guidelines are stated in Section 3.3.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">And for each property specified afterwards, property-specific privacy considerations are stated respectively.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">Take network_access for instance: There is concern about undesirable privacy leakage via network_access properties to distrusted ALTO clients. In such cases, according to the definitions above, either the endpoint itself or the ISP who is running the ALTO server can either specify an access control policy to prevent undesirable exposure to specific ALTO clients or use a privacy preserving mapping from the raw description of access technologies to a number of abstract relative ranking information instead. Moreover, the endpoint or the ISP might choose to use another subscription related property "provisioned_bandwidth" (defined later in Section 4.4.2) instead of "network_access".</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">SS (Sergey Slovetskiy): What defines what is in scope / out of scope?</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">JS: ALTO Prolem Statement</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">SS: Fast-changing properties may be important for CDNs.</span></p>
<p class="ecxMsoPlainText"><span lang="EN-US">[dll]: Would be happy to hear more about this consideration, and let the WG decide if they are suitable to be defined as endpoint properties.</span></p>
</div>
<div><br></div>
<div><br></div>
<br><div>---------<br>&#37011;&#28789;&#33673;<br><br>&#20013;&#22269;&#31227;&#21160;&#36890;&#20449;&#30740;&#31350;&#38498;<br><br>denglingli <at> chinamobile.com<div><br></div>
</div>&lt;!--
.ExternalClass .ecxgrayEdit {
color:#999999;
}

.ExternalClass .ecxgrayPreEdit {
color:#999999;
background:#316AC5;
}

.ExternalClass {
}
--&gt;----&#37038;&#20214;&#21407;&#25991;----<br>&#21457;&#20214;&#20154;&#65306;internet-drafts&nbsp;&lt;internet-drafts <at> ietf.org&gt;<br>&#25910;&#20214;&#20154;&#65306;Haibin&nbsp;Song&nbsp;&lt;haibin.song <at> huawei.com&gt;,Qin&nbsp;Wu&nbsp;&lt;sunseawq <at> huawei.com&gt;,Wenson&nbsp;Wu&nbsp;&lt;sunseawq <at> huawei.com&gt;,Richard&nbsp;Yang&nbsp;&lt;yry <at> cs.yale.edu&gt;,Haibin&nbsp;Song&nbsp;&lt;haibin.song <at> huawei.com&gt;,Deng&nbsp;Lingli&nbsp;&lt;denglingli <at> chinamobile.com&gt;,Sebastian&nbsp;Kiesel&nbsp;&lt;ietf-alto <at> skiesel.de&gt;,Yang&nbsp;Yang&nbsp;&lt;yry <at> cs.yale.edu&gt;,Lingli&nbsp;Deng&nbsp;&lt;denglingli <at> chinamobile.com&gt;,Sebastian&nbsp;Kiesel&nbsp;&lt;ietf-alto <at> skiesel.de&gt;<br>&#25220;&#12288;&#36865;:&nbsp;(&#26080;)<br>&#21457;&#36865;&#26102;&#38388;&#65306;2015-06-11&nbsp;09:09:45<br>&#20027;&#39064;&#65306;New&nbsp;Version&nbsp;Notification&nbsp;for&nbsp;draft-deng-alto-p2p-ext-06.txt<br><br><br>A&nbsp;new&nbsp;version&nbsp;of&nbsp;I-D,&nbsp;draft-deng-alto-p2p-ext-06.txt
<br>has&nbsp;been&nbsp;successfully&nbsp;submitted&nbsp;by&nbsp;Lingli&nbsp;Deng&nbsp;and&nbsp;posted&nbsp;to&nbsp;the
<br>IETF&nbsp;repository.
<br><br>Name:		draft-deng-alto-p2p-ext
<br>Revision:	06
<br>Title:		Extended&nbsp;End&nbsp;Point&nbsp;Properties&nbsp;for&nbsp;Application-Layer&nbsp;Traffic&nbsp;Optimization
<br>Document&nbsp;date:	2015-06-10
<br>Group:		Individual&nbsp;Submission
<br>Pages:		18
<br>URL:&nbsp;https://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-06.txt
<br>Status:&nbsp;https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
<br>Htmlized:&nbsp;https://tools.ietf.org/html/draft-deng-alto-p2p-ext-06
<br>Diff:&nbsp;https://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-06
<br><br>Abstract:
<br>&nbsp;The&nbsp;purpose&nbsp;of&nbsp;the&nbsp;Application-Layer&nbsp;Traffic&nbsp;Optimization&nbsp;(ALTO)
<br>&nbsp;protocol&nbsp;is&nbsp;to&nbsp;provide&nbsp;better-than-random&nbsp;peer&nbsp;selection&nbsp;for&nbsp;P2P
<br>&nbsp;networks.&nbsp;The&nbsp;base&nbsp;ALTO&nbsp;protocol&nbsp;focuses,&nbsp;only&nbsp;on&nbsp;providing&nbsp;network
<br>&nbsp;topological&nbsp;location&nbsp;information&nbsp;(i.e.,&nbsp;network&nbsp;maps&nbsp;and&nbsp;cost&nbsp;maps).
<br>&nbsp;However,&nbsp;the&nbsp;peer&nbsp;selection&nbsp;method&nbsp;of&nbsp;an&nbsp;endpoint&nbsp;may&nbsp;also&nbsp;use&nbsp;other
<br>&nbsp;properties,&nbsp;such&nbsp;as&nbsp;geographic&nbsp;location.&nbsp;This&nbsp;document&nbsp;defines&nbsp;a
<br>&nbsp;framework&nbsp;and&nbsp;an&nbsp;extended&nbsp;set&nbsp;of&nbsp;End&nbsp;Point&nbsp;properties&nbsp;(EP&nbsp;properties)
<br>&nbsp;to&nbsp;extend&nbsp;the&nbsp;base&nbsp;ALTO&nbsp;protocol.
<br><br>&nbsp;
<br><br><br>Please&nbsp;note&nbsp;that&nbsp;it&nbsp;may&nbsp;take&nbsp;a&nbsp;couple&nbsp;of&nbsp;minutes&nbsp;from&nbsp;the&nbsp;time&nbsp;of&nbsp;submission
<br>until&nbsp;the&nbsp;htmlized&nbsp;version&nbsp;and&nbsp;diff&nbsp;are&nbsp;available&nbsp;at&nbsp;tools.ietf.org.
<br><br>The&nbsp;IETF&nbsp;Secretariat
<br><br><br>Subject&#65306;New&nbsp;Version&nbsp;Notification&nbsp;for&nbsp;draft-deng-alto-p2p-ext-06.txt<br><br><br>A&nbsp;new&nbsp;version&nbsp;of&nbsp;I-D,&nbsp;draft-deng-alto-p2p-ext-06.txt
<br>has&nbsp;been&nbsp;successfully&nbsp;submitted&nbsp;by&nbsp;Lingli&nbsp;Deng&nbsp;and&nbsp;posted&nbsp;to&nbsp;the
<br>IETF&nbsp;repository.
<br><br>Name:		draft-deng-alto-p2p-ext
<br>Revision:	06
<br>Title:		Extended&nbsp;End&nbsp;Point&nbsp;Properties&nbsp;for&nbsp;Application-Layer&nbsp;Traffic&nbsp;Optimization
<br>Document&nbsp;date:	2015-06-10
<br>Group:		Individual&nbsp;Submission
<br>Pages:		18
<br>URL:&nbsp;https://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-06.txt
<br>Status:&nbsp;https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
<br>Htmlized:&nbsp;https://tools.ietf.org/html/draft-deng-alto-p2p-ext-06
<br>Diff:&nbsp;https://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-06
<br><br>Abstract:
<br>&nbsp;The&nbsp;purpose&nbsp;of&nbsp;the&nbsp;Application-Layer&nbsp;Traffic&nbsp;Optimization&nbsp;(ALTO)
<br>&nbsp;protocol&nbsp;is&nbsp;to&nbsp;provide&nbsp;better-than-random&nbsp;peer&nbsp;selection&nbsp;for&nbsp;P2P
<br>&nbsp;networks.&nbsp;The&nbsp;base&nbsp;ALTO&nbsp;protocol&nbsp;focuses,&nbsp;only&nbsp;on&nbsp;providing&nbsp;network
<br>&nbsp;topological&nbsp;location&nbsp;information&nbsp;(i.e.,&nbsp;network&nbsp;maps&nbsp;and&nbsp;cost&nbsp;maps).
<br>&nbsp;However,&nbsp;the&nbsp;peer&nbsp;selection&nbsp;method&nbsp;of&nbsp;an&nbsp;endpoint&nbsp;may&nbsp;also&nbsp;use&nbsp;other
<br>&nbsp;properties,&nbsp;such&nbsp;as&nbsp;geographic&nbsp;location.&nbsp;This&nbsp;document&nbsp;defines&nbsp;a
<br>&nbsp;framework&nbsp;and&nbsp;an&nbsp;extended&nbsp;set&nbsp;of&nbsp;End&nbsp;Point&nbsp;properties&nbsp;(EP&nbsp;properties)
<br>&nbsp;to&nbsp;extend&nbsp;the&nbsp;base&nbsp;ALTO&nbsp;protocol.
<br><br>&nbsp;
<br><br><br>Please&nbsp;note&nbsp;that&nbsp;it&nbsp;may&nbsp;take&nbsp;a&nbsp;couple&nbsp;of&nbsp;minutes&nbsp;from&nbsp;the&nbsp;time&nbsp;of&nbsp;submission
<br>until&nbsp;the&nbsp;htmlized&nbsp;version&nbsp;and&nbsp;diff&nbsp;are&nbsp;available&nbsp;at&nbsp;tools.ietf.org.
<br><br>The&nbsp;IETF&nbsp;Secretariat
<br><br><br><div>
<br><br>
</div>
</div>
</div>
 		 	   		  </div></div>
Wendy Roome | 4 Jun 21:34 2015

ALTO Interop test in July

To get the ball rolling on an ALTO interop test, I have submitted
draft-roome-interop-ietf93-00. Please, please, someone else please read it.

https://datatracker.ietf.org/doc/draft-roome-interop-ietf93/

It specifies quite a lot: two network maps, two cost metrics, and a custom
property. However, only *required* resources are the default network map,
one routingcost cost map (numerical or ordinal), and an EPS for the
default network's pid property. Everything else is optional.

	- Wendy Roome

Lingli Deng | 3 Jun 08:54 2015

Question about unified framework for properties

Hi Wendy,

I am currently working on a revision for draft on Extended endpoint properties (I.D-draft-deng-alto-p2p-ext),  and noticed there is concern about potential overlap during last meeting with your proposal on a unified framework for properties.
I am afraid that I was not there for the onsite discussion, but after reading your slides, I feel it seems to be orthogonal with endpoint properties. What do you think?
BTW, I could not find any draft for the proposed framework. Are you working on such a document or is there anybody else doing this? If so, I would be happy to read it and double check its relevance with or effect on our work on endpoint properties.

Regards,
Lingli
<div><div dir="ltr">Hi Wendy,<div><br></div>
<div>I am currently working on a revision for draft on&nbsp;<span>Extended endpoint properties (I.D-</span><span>draft-deng-alto-p2p-ext</span><span>)</span><span>, &nbsp;and noticed there is concern about potential overlap during last meeting with your&nbsp;proposal on a unified framework for properties.</span>
</div>
<div>I am afraid that I was not there for the onsite discussion, but after reading your slides, I feel it seems to be&nbsp;<span>orthogonal with endpoint properties. What do you think?</span>
</div>
<div><span>BTW, I could not find any draft for the proposed framework. Are you working on such a document or is there anybody else doing this? If so, I would be happy to read it and double check its relevance with or effect on our work on endpoint properties.</span></div>
<div><span><br></span></div>
<div><span>Regards,</span></div>
<div><span>Lingli</span></div> 		 	   		  </div></div>
Wendy Roome | 1 Jun 18:29 2015

Re: Representing strict cost metrics

Assuming we go forward with strict metrics, here is how we could do it
without breaking legacy clients.

There are two separate issues. One is letting clients know that a metric
obeys the requirements for a formal metric. That can be handled by
requiring anyone who registers a metric with the IANA to say whether or
not it is a formal metric.

The second issue is how to take advantage of the redundancy. If the server
just omitted the zero-diagonal and the lower half of the cost map for any
metric defined as strict, then a legacy client (or a smart client using a
legacy ALTO access library) will get an incomplete cost map. We can solve
that problem by defining a new cost mode, say "strict". This means that
for this cost-type, the server will omit the 0-diagonal and the lower half
of the cost map. The client is expected deduce those values.

Then if (say) the metric geo-distance obeys the formal metric rules, a
server can offer geo-distance in *both* the numerical & strict modes. The
strict-mode cost map omits the redundant cost points, while the
numerical-mode cost map includes them.

Thus a client which knows about the strict-mode extension will request
strict mode, and will supply the implicit costs. But a legacy client will
ignore the unknown mode, and will request the numerical mode instead. So
the legacy client still will get a valid geo-distance cost map, with all
the cost points. It just won't be as efficient.

Does that sound reasonable?

	- Wendy

On 05/31/2015, 22:39, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz <at> sprint.com>
wrote:

>Richard,
>
>You are not too far off at all.  We need to think about this carefully.
>The team I work in is looking to set up topology information in such a
>way that NFV MANO and VIM decisions are simple while still providing some
>traditional transport optimization.
>
>I also think we may need theorems for aggregation of metrics.  I'll have
>to dust off old work by various folks to see if it has not already been
>figured out.
>
>Since cost maps are directed there is no reason why we can't compute max
>and sum distance.  This is practically an exercise left to the reader.
>The symmetric case would be new though.
>
>wrt the July question we may be able to do some work with the old code
>and there may be other code available as well but that will be quite new
>and full of bugs.   I hope to confirm this before the end of June.
>
>Lyle
>

internet-drafts | 29 May 16:36 2015
Picon

I-D Action: draft-ietf-alto-incr-update-sse-00.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 Working Group 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-00.txt
	Pages           : 27
	Date            : 2015-05-29

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-00

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/

Wendy Roome | 29 May 16:24 2015

Re: Interop test

Folks,

Rather than simply update the last test, I suggest a new approach,
outlined below.

**** General ****

The interop test defines two network maps: the default network map and an
alternate network map. We specify the PIDs and CIDRs for each map. For
each network map, the interop test defines the numerical-mode values for
the routingcost and hopcount cost-metrics. The interop test does not
define ordinal values for those metrics. Instead, each ALTO server may
assign ordinal values however it wants, as long as the ordinal values
preserve the numerical values.

The interop test also defines a custom endpoint property, say
"priv:ietf-type", and specifies the values.

**** Approach & Philosophy ****

Rather than specifying every detail, as in the previous interop test, this
iteration only specifies what is absolutely necessary. That is, the PIDs
in the network maps, the costs between PIDs, and the enpdoint property
values. Everything else -- resource ids, uris, cost-type names, etc. -- is
up to the server. Thus each server is completely characterized by two
parameters:

* The URI of its IRD.
* The resource id of its alternate map (if provided).

When a client is paired with a server, the client is given those two
parameters. The client is expected to determine everything else it needs
(e.g., the URIs of the default network map and the numerical routingcost
cost map) from the IRD.

Client-writers are encouraged to script their client so that it validates
the server's responses. That is, rather than just printing a cost map, the
client is encouraged to verify that it has the expected values. The
interop test will specify the maps in enough detail that clients will know
exactly what the server should return for any request.

Server-writers are encouraged to configure their server (especially the
IRD) so as to stress-test clients. That is, do things which are legal, but
unusual. For example, instead of having all resources in one IRD, the
server might have several linked (cascaded) IRDs. Or instead of offering
one filtered cost map, which handles all four combinations of cost metrics
& modes, plus constraints, the server might offer four separate filtered
cost map resources: one which handles numerical mode routingcost &
hopcount, but does not accept constraints, a second that handles the same
cost types, but which does accept constraints, and two more for ordinal
mode costs. This would verify that a client is able to select the correct
resource for a given request.

**** Server Requirements ****

Each server MUST offer the following resources:
* A full network map for the default network.
* Four full cost maps for the default network map: the routingcost &
hopcount metrics, in both numerical & ordinal modes.
* An endpoint property service for the pid property for the default
network map.

Each server MAY offer the following optional services:
* A filtered network map for the default network.
* A filtered cost map for the default network, optionally allowing cost
constraints.
* An endpoint cost service, covering the 4 cost metric/mode combinations,
optionally allowing cost constraints. The values must be derived from the
default network & cost maps.
* The filtered cost map & endpoint cost services may support constraints.
* An alternate network map plus the 4 associated full cost maps.
* An endpoint property service for the alternate network's pid property.
This may be the same EPS resource as for the default network, or a
different resource.
* A filtered network map for the alternate network.
* A filtered cost map for the alternate network map.

If offered, the filtered cost map & endpoint cost resources MUST cover all
four metric/mode combinations.

If offered, the costs for the endpoint cost service MUST must be derived
from the default network map.

**** Client Requirements ****

When a client is paired with a server, the client is given the URI of the
server's IRD, and the resource id of its alternate map (if the server &
client support alternate maps). The client must be able to extract all
other information from the IRD -- full map resources, their URIs, etc.

Each client MUST:

* Fetch the IRD.
* Locate & fetch the default network map and its four associated full cost
maps.
* Locate the EPS for the default network map's pid resource, and determine
the pid for a set of endpoints specified by the interop test.

Note that clients are not required to fetch the alternate network map (if
present). But every client must be able to parse an IRD with an alternate
network map, and distinguish the default network map, and its associate
resources, from the alternate map.

Optional client requirements:
* Use the filtered network map for the default network map to fetch PIDs
specified by the interop test.
* Use the filtered cost map for the default network map to fetch the costs
for several combinations of source pids, destination pids, metrics/modes,
and optional constraints, as specified by the interop test.
* Use the endpoint cost service to fetch the costs for several
combinations of source addresses, destination addresses, metrics/modes,
and optional constraints, as specified by the interop test.
* Locate & fetch the alternate map and its four full cost maps.
* Use the filtered network map for the alternate network map to fetch PIDs
specified by the interop test.
* Use the filtered cost map for the alternate network map to fetch the
costs for several combinations of source pids, destination pids,
metrics/modes, and optional constraints, as specified by the interop test.
* Fetch the custom endpoint property for a set of endpoints defined by the
interop test.

**** Error Testing ****

We will develop "torture test" scripts of bad client requests, and feed
them to each server to make sure the server gives reasonable error
responses. Participants are encouraged to contribute bad client requests
up to the time of the test. We will not specify the error tests in
advance, but will publish them after the interop is complete.

Note that the emphasis in on verifying that servers survive client errors.
It does not seem important to verify that clients survive server errors.
If you disagree, speak now or forever hold your peace.

    - Wendy Roome


Gmane