draft-ietf-alto-multi-cost-07.txt   draft-ietf-alto-multi-cost-08.txt 
Network Working Group S. Randriamasy Network Working Group S. Randriamasy
Internet-Draft W. Roome Internet-Draft W. Roome
Intended status: Standards Track Nokia Bell Labs Intended status: Standards Track Nokia Bell Labs
Expires: September 11, 2017 N. Schwan Expires: October 7, 2017 N. Schwan
Thales Deutschland Thales Deutschland
March 10, 2017 April 5, 2017
Multi-Cost ALTO Multi-Cost ALTO
draft-ietf-alto-multi-cost-07 draft-ietf-alto-multi-cost-08
Abstract Abstract
The ALTO (Application Layer-Traffic Optimization) Protocol The ALTO (Application Layer-Traffic Optimization) Protocol
([RFC7285]) defines several services that return various metrics ([RFC7285]) defines several services that return various metrics
describing the costs between network endpoints. An ALTO Server may describing the costs between network endpoints. An ALTO Server may
offer a variety of cost metrics, based on latency,bandwidth, hop offer a variety of cost metrics, based on latency,bandwidth, hop
count, jitter, or whatever else the ALTO Server deems useful. For count, jitter, or whatever else the ALTO Server deems useful. For
example, when downloading a file that is mirrored on several sites, a example, when downloading a file that is mirrored on several sites, a
user application may consider more than one metric, perhaps trading user application may consider more than one metric, perhaps trading
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2017. This Internet-Draft will expire on October 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 21 skipping to change at page 10, line 21
Therefore the Multi-Cost ALTO protocol extension defines the Therefore the Multi-Cost ALTO protocol extension defines the
capability field "testable-cost-type-names". Like "cost-type-names", capability field "testable-cost-type-names". Like "cost-type-names",
it is an array of cost type names. If present, that resource only it is an array of cost type names. If present, that resource only
allows constraint tests on the cost types in that list. "testable- allows constraint tests on the cost types in that list. "testable-
cost-type-names" must be a subset of "cost-type-names". cost-type-names" must be a subset of "cost-type-names".
3.6.5. Legacy ALTO Client issues 3.6.5. Legacy ALTO Client issues
While a multi-cost-aware Client will recognize the "testable-cost- While a multi-cost-aware Client will recognize the "testable-cost-
type-names" field, and will honor those restrictions, a legacy Client type-names" field, and will honor those restrictions, a legacy Client
will not. Hence a legacy may send a request with a constraint test will not. Hence a legacy client may send a request with a constraint
on any of the cost types listed in "cost-type-names". test on any of the cost types listed in "cost-type-names".
To avoid that problem, the "testable-cost-type-names" and "cost- To avoid that problem, the "testable-cost-type-names" and "cost-
constraints" fields are mutually exclusive: a resource may define one constraints" fields are mutually exclusive: a resource may define one
or the other capability, but must not define both. Thus a resource or the other capability, but must not define both. Thus a resource
that does not allow constraint tests on all cost metrics will set that does not allow constraint tests on all cost metrics will set
"testable-cost-type-names" to the testable metrics, and will set "testable-cost-type-names" to the testable metrics, and will set
"cost-constraints" to "false". A multi-cost-aware Client will "cost-constraints" to "false". A multi-cost-aware Client will
recognize the "testable-cost-type-names" field, and will realize that recognize the "testable-cost-type-names" field, and will realize that
its existence means the resource does allow (limited) constraint its existence means the resource does allow (limited) constraint
tests, while a legacy Client will think that resource does not allow tests, while a legacy Client will think that resource does not allow
skipping to change at page 18, line 5 skipping to change at page 17, line 51
4.2.3. Response 4.2.3. Response
The extensions to the Endpoint Cost Service response are similar to The extensions to the Endpoint Cost Service response are similar to
the extensions to the Filtered Cost Map response (Section 4.1.3). the extensions to the Filtered Cost Map response (Section 4.1.3).
Specifically, if the Client specifies the "cost-type" input Specifically, if the Client specifies the "cost-type" input
parameter, the response is exactly as defined in {11.5.1.6} of parameter, the response is exactly as defined in {11.5.1.6} of
[RFC7285]. If the Client provides the "multi-cost-types" instead, [RFC7285]. If the Client provides the "multi-cost-types" instead,
then the response is changed as follows: then the response is changed as follows:
o In "meta", the field "cost-type" is provided with a dummy value. o In "meta", the value of field "cost-type" will be ignored by the
Instead, the field "multi-cost-types" is added with the same value receiver and set to {}. Instead, the field "multi-cost-types" is
as the "multi-cost-types" input parameter. added with the same value as the "multi-cost-types" input
parameter.
o The costs are JSONArrays, instead of JSONNumbers. All arrays have o The costs are JSONArrays, instead of JSONNumbers. All arrays have
the same cardinality as the "multi-cost-types" input parameter, the same cardinality as the "multi-cost-types" input parameter,
and contain the cost type values in that order. If a cost type is and contain the cost type values in that order. If a cost type is
not available for a particular source and destination, the ALTO not available for a particular source and destination, the ALTO
Server MUST use the JSON "null" value for that array element. If Server MUST use the JSON "null" value for that array element. If
none of the cost types are available for a particular source and none of the cost types are available for a particular source and
destination, the ALTO Server MAY omit the entry for that source destination, the ALTO Server MAY omit the entry for that source
and destination. and destination.
skipping to change at page 28, line 5 skipping to change at page 27, line 48
6. IANA Considerations 6. IANA Considerations
This document does not define any new media types or introduce any This document does not define any new media types or introduce any
new IANA considerations. new IANA considerations.
7. Privacy And Security Considerations 7. Privacy And Security Considerations
This document does not introduce any privacy or security issues not This document does not introduce any privacy or security issues not
already present in the ALTO protocol. already present in the ALTO protocol.
The Multi-Cost optimization even tends to reduce the on the wire data
exchange volume, compared to multiple single cost ALTO transactions.
Likewise, the risk related to massive Multi-Cost requests is
moderated by the fact that Multi-Cost constraints additionally filter
ALTO Server responses and thus reduce their volume.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Richard Alimi, Fred Baker, Dhruv The authors would like to thank Richard Alimi, Fred Baker, Dhruv
Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for
fruitful discussions and feedback on this document and previous fruitful discussions and feedback on this document and previous
versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang
Xin provided substantial review feedback and suggestions to the Xin provided substantial review feedback and suggestions to the
protocol design. protocol design.
9. References 9. References
 End of changes. 7 change blocks. 
9 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/