Minutes for ALTO at IETF-90
minutes-90-alto-1

          IETF 90, Toronto, ON (Canada)
          Friday Jul 25, 2014
          ALTO Working Group Meeting 1150-1320, Tudor 7/8
          Enrico Marocco, Vijay K. Gurbani

          1301-1315 - ALTO cost calendar and multi-cost           S.
          Randriamasy      14'
                      draft-randriamasy-alto-cost-calendar-00
                      draft-randriamasy-alto-multi-cost-08

          1315-1320 -

--------------------------------------------
Jan Seedorf replaces Vijay Gurbani in chairing this ALTO session
Note takers Sabine and Dhruv
Name Abbreviations
EM = Enrico Marocco
JP = Jon Peterson
JS = Jan Seedorf
KM = Kevin Ma
LD = Lingli Deng
LE = Lars Eggert
MS = Martin Stiemerling
QW = Qin Wu
RT = Rick Taylor
RY = Richard Yang
SK = Sebestian Kiesel
SP = Stefano Previdi
SR = Sabine Randriamasy
--------------------------------------------

------ Administrivia Chairs
Presentation Enrico Marocco

We are now in the second life of the ALTO WG
Status: charter has been adopted, we are comitted to deliver chartered
extension items. Extensions for protocol optimization, enhanced discovery,
protocol extensions, graph representation. ALTO protocol in AUTH48, will be RFC
7285 ALTO Server discovery will be RFC 7286

------ Endpoint properties for peer selection
draft-deng-alto-p2p-ext-01
Presentation Lingli: A very large group work on this draft to extend EP props.

Rick Taylor: have you looked at non-broadband ISP home networks ISH (I come
from MANET)? Lingli Deng: Yes. so he will take it on list. Martin Stiemerling:
there are a lots of things that are too volatile to belong to an AOS. e.g.
coverage which is so variable. LD: we agree and want to discuss it on the list.
Lars Eggert: some characteristics are very technology specific. ADSL could mean
anything. Uplink and downlink capacities are different and variable and time
sensitive. LD: we can use an abstraction like ranking on this. Richard Yang:
the technology may change. This draft proposes to have a compensation. When
technology changes quicly there is a loss of performance. Jan Seedorf: ALTO
does not support quickly changes LE: ALTO conveys info that cannot be retrived
otherwise. EM: we need take these discussions to mailing list

------ ALTO PID properties
draft-roome-alto-pid-properties-02
Presentation Richard Yang: Complements the Deng draft. Number of EP can be in
order of billions, config setting and retrieving not scalable. Base idea is
information aggregation.

LE: I don't think information is that big.
RY: file size is estimated to be 2 GIG
LE: this is not so big
JS: but if you want to download. We are conveying this info on network, if
hundred thousands of EP properties are the same, we can aggregate. Stefano
Previdi: I didn't miss much since my last meetings. We still argue on "should I
download a big file or should I get only what I need?". EM: ALTO supports both
SP: the ALTO Deployments I know of are based more on transactions rather than
batch transfer. EM: you have your name on the protocol... JS: I have a
different Use Case: download batch in CDN. Property inheritance may help there.
RY: we also have a UC where we need to do a batch transfer

------ ALTO for CDNI FCI progress
draft-seedorf-cdni-request-routing-alto-07
Presentation Jan Seedorf: CDNi FCI. Is a compromise and synthesis between 2
drafts.

EM: ALTO should definitely have such a UC for ALTO.
Jon Peterson: we need guidelines for using such ALTO servers for other groups
such as CDNi. Martin Stiemerling  for Sebastian Kiesel: does it make sense to
use ALTO network maps with PID. JP: we tried it was ugly to use ALTO maps to
express this. So we used PIDs as footprints. See example ALTOless. Kevin Ma: we
did not want to constraint to use or not to use ALTO. That is, we allow ALTO
but it is not mandatory. JP: There a lots of other mechanisms. I didn't want
ALTO to close door on using other things. KM: going to start on ALTO, will look
if FCI is usable for ALTO. EM: ALTO is a framwork to convey info. JP: that is
right, it would be good to get doc on how to use ALTO

------ ALTO traffic engineering cost metrics
draft-wu-alto-te-metrics-03
Presentation Qin Wu

RT: the ALTO charter is not about dynamic updating. Some of these metrics are
dynamic. Latency changes often. if average over minute you are real time. If
over a week, this has no use. EM: residual bandwidth changes less frequently.
RT: apps want to have a rough idea but must still be precise. EM: currently
regardless of charter, we look at whether such metrics are useful. MS: old
charter does not care about instant information such as RTT. In this draft you
try to re-define metrics already specified elsewhere. SP: what you address is
valuable. But this is already solved in the routing area. You shoud have a
look. We already have model and API for this. RY on Stefano: what doc? Stefano:
BGP-LS Richard: but we want something simple for apps. Stefano: this is what we
do. Lars: you propose packetloss: not unrelated to congestion control. Because
radio link ok. But you need to say what you mean with this metic RY: this doc
does not redefine metrics. LE: packet loss depends on what kind of traffic, how
it is scheduled. RY: excellent comment

------ ALTO topology representation
draft-scharf-alto-topology-00 - draft-yang-alto-topology-03
Presentation Richard Yang: Yale has a huge network moving large data around.
Astronomy etc.. See the Multi-flow scheduling example. E2E paths may use
different routes. Path vector example. Want feedback from the WG on graph
represetnation. Good for ALTO but controverisial with other WGs. We propose
example conveying the routing method (SP) together with the path. Feedback is
wellcome. We will merge 2 drafts for IETF91.

------ ALTO cross-domain server discovery -
draft-kiesel-alto-xdom-disc-00 - draft-kiesel-alto-xdom-disc-alg-00
Presentation Martin: ALTO Client may be in the tracker. Partitioned ALTO
knowledge. JP: did you look at lost - forest (?)

------ ALTO Anycast address
draft-kiesel-alto-ip-based-srv-disc-03

Martin: Any cast = Charter item?
Enrico: is someone opposed to adopt anycast as a basis for the WG? It is simple
and straightforward. Jon: there is many existing work so why? Lars: use a
service record (?) Martin: (?) people say no.

------ ALTO cost calendar and multi-cost
draft-randriamasy-alto-multi-cost-08
draft-randriamasy-alto-cost-calendar-00
Presentation Sabine Randriamasy

(See also Dhruv's notes)
Rick: we have extensions on metrics and forecasting. What is the plan of the WG
with this work? I mean this is great. Jan: there has been few discussion on the
list Sabine: I wouldn't say that because this is how we ended up editing the
Calendar draft with many authors and besides calendaring is now a re-chartering
item. Jan: agree Rick: there is a consistent definition of ALTO time intervals
Sabine: let me recall: "ALTO time interval T" means ALTO server just says "I
give you the value during T" and how the values were measured is out of scope.

------ Session closes ------ ------ ------ ------ ------