Meeting notes from ALTO WG meeting, IETF82, Taipei, Taiwan
Wednesday, November 16, 13:00-15:00

About 100 attendees

This report has been distilled from the detailed meeting notes taken
by Jan Seedorf and Ben Niven-Jenkins

Chairs: Vijay Gurbani (remote) , Enrico Marocco and Jon Peterson (as acting
chair).

Agenda
------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Enrico starts session and welcomes Jon as acting chair (Vijay could
not attend IETF82). Related work ongoing elsewhere: JSON patch for
incremental updates and JOSE WG for integrity protection that could be
reused for ALTO information redistribution.

  No questions nor comments.

Requirements
------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Martin Stiemerling presents ALTO requirements, changes requested by AD
review and APPS team review have been addressed in latest revision
(-12) of the draft, no comments from WG.

  No questions nor comments.


ALTO protocol
-------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Rich Alimi presents ALTO protocol draft; Rich presents functional and
editorial changes since the last version of the draft; Rich presents
discussion items (see slides for details).

  Martin: what is the reason for having non-number costs, do not see
  the use case right now? Rich: should make sure that ALTO supports
  this in case this is needed. Martin: recommends to finish spec soon.

  Enrico: this is very important extensibility point so important to
  get feedback from people who are thinking about alto for different
  use cases - CDNI comes to mind. Bring comments to the list.

Rich presents possible protocol extensions.

  Stefano: are we going to address the "authoritativeness"?; Jon:
  probably do not want to do this in the base spec.

  Ted Hardie: can somebody provide costs for PIDs which are defined by
  somebody else? Rich: currently this is not possible nor
  envisioned. Ted: makes sense but it's the "I'm guessing bit" that
  confused me because the ALTO server is in a context it's defined.
  Rich: instead of authoritativeness confidence is probably a better
  word. Ted: it sounds closer to what you said.


JOSE WG intro
-------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Jim Schaad gives an overview on the new "jose" WG; jose has the goals
of providing integrity protection, encryption protection, and crypto
keys as JSON notation.

  No questions or comments.


ALTO server discovery protocol
------------------------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Martin presents ALTO server discovery protocol; Martin discusses
changes in the U-NAPTR process. Asked for DNS directorate review, but
did not hear back

  Andrew Sullivan (co-chair of DNSext WG): my colleague Oliver has
  completed review & sent to DNS directorate list. Process it goes to
  AD and he sends it to you. There are some significant issues though
  e.g. reverse DNS lookup for Ipv6. Tree climbing in DNS is either
  icky or unspeakably bad (depends who you ask) but tree climbing with
  IPv6 is really going to suck. Martin: that why is asked for review
  what text should we write in the draft. Andrew: use a different
  protocol, traditionally what happens when DNS geeks see that sort of
  thing but unfortunate thing I don't have a better option for
  you. This is just always a problem when people do tree climbing in
  DNS and we don't have a good answer for it. I will think hard about
  it (I only just heard about this yesterday).

  Rich: if some of those issues were to become blocking it seems that
  if discovery can be handled in app itself (e.g. P2P client) there
  are other options that might go in initial version and leave
  sticky/icky stuff to a future draft/version.

  Dave Harrington (responsible AD): I checked through my mail and I
  can't see the DNS directorate review - it's not that I haven't
  forwarded it, I haven't received it yet. Andrew: it's in flight,
  might be with DNS AD.

  Andrew: another issue in the draft is reverse DNS, as it talks about
  managing rDNS tree and how stuff gets in there. We have tried for
  many years now to state something authoritatively about how to
  maintain DNS tree and answer from OPS community is always "go away,
  get off my lawn, I'll do it how I want". Suggest OPS consideration
  section that talks about heuristic if this thing fails or get an
  answer that points you to the wrong place because forward/back don't
  match or point to different domains.


Deployment considerations
-------------------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Martin presents ALTO deployment considerations; Martin presents
changes in -03 version of the draft.

  Enrico: chairs will volunteer a couple of reviewers to provide early
  review.

  Ted: pointer to ALTO-CDN draft needs to be updated. Stefano Previdi:
  ALTO-CDN drafts have been merged, so there is a new draft. Ted: does
  WG intend to progress a draft where DNS resolution is point at which
  ALTO server is queried? If WG does go down this path then need to go
  talk to your DNS geeks one more time as could get tricky very
  fast. Stefano: text reports on reality of deployments, not on how
  ALTO could be used for CDN optimization.


ALTO in home proxies
--------------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

FabiO Picconi presents ALTO home proxy draft; approach is to have an
ALTO proxy located at home gateways. Fabio presents benefits of this
approach.

  Rich: what about user privacy? Ted: redistribution via home proxy
  has privacy issues. Fabio: mentioned in the draft.

  Reneildo Penno: like this idea.

  Rich: many concepts in the draft are more general than just home
  proxies.

  Martin: the deployments draft has a section about cascading ALTO
  servers, this is related and should be looked at.

  Ted: interception proxy at home is not a good idea, local ALTO
  server on the other hand makes sense (e.g. makes discovery much
  easier). Fabio: interception proxy is considered because home
  gateways are becoming more powerful. Ted: proxy would need to look
  at each http request to check if it is ALTO or not. Fabio: idea is
  that home gateway is already looking at each http request, not only
  for ALTO.

  Haibin Song: mentioned ALTO info could be updated in off-peak hours
  but ALTO server may want apps to use more update info. Fabio: agree
  we are not saying how to distribute updates, just an observation if
  device is always on then have a wider range of choices of when to
  fetch that information, e..g if detect ALTO server load is low could
  push information. Haibin: if no indication from ALTO server to proxy
  on whether cost/network map can be updated later then best way for
  proxy/redist gateway is to fetch ALTO information immediately is my
  view.

  Reinaldo - I like this idea, with any idea there are snags that need
  tuning. Like idea of DNS ALTO proxy so maybe can look at DNS request
  and based on ALTO requests give more proximity on DNS replies.

  Rich: redistribution & other concepts in here are more general than
  just home proxies. I'd like it if a lot of those concepts were
  extended and applicable beyond home proxies whether in this document
  or somewhere else. Would like these things preserve.

  Ted: why in context of proxies & not ALTO servers? Fabio: covered
  in later slides.

  Martin: something about cascading alto servers in deployment
  consideration, not exactly the same but you should probably read it.

  Enrico: concern coming from chairs - deployment considerations seems
  a good place to document these use cases.

  Ted: seems a bit odd to introduce intercept proxy & getting hotel
  network at home just for ALTO response seems odd because it has to
  look at every HTTP request to figure out which ones are
  ALTO. Approaching this as HTTP proxy in general will generate more
  problems that it solves. On other hand if willing to run as local
  server you are making discovery problem much more tractable. If go
  forward maybe focus on how to really successfully run local server
  would be useful, running intercepting proxy to get this done is
  catching an elephant to catch a knat. Fabio: definitely good
  point. Considering intercepting proxy as option as home gateways
  getting more powerful with Atom based CPUs etc. intercepting proxy
  could be there for lots of reasons. Ted: it so much worse than you
  think. In order to prevent someone using HTTPS version of u-NAPTR
  query you'll have to tell them not to use TLS. Assuming include
  unsigned u-NAPTR record you'll have to take out HTTPS response and
  then you break DNSSEC. So you'd need a proxy to intercept DNS and
  HTTP that in path of vast majority of queries through the gateway
  just to cache a handful of ALTO queries a day. This doesn't seem
  right place to optimise. Fabio: wouldn't look at all HTTP requests.
  Ted: how do you manage that? Fabio: gateway will already be
  intercepting all HTTP requests. Adding ALTO feature to gateway
  that's already intercepting HTTP. Ted: document doesn't say
  that.. it's not clear. Fabio: will make it clear. If client wants to
  use TLS to verify server then falling back top HTTP is a problem but
  could fall back to HTTP and have response signed by ALTO server.
  Ted: client gets something to tell it ito use TLS so it's
  uncacheable. If already doing it for some other reason then in that
  situation you'll already get it from HTTP cache - nothing special
  you need to do. If you're trying to get a cache hit when you
  wouldn't normally it's a massive rat hole.

  Rich: asked about changes to HTTP. HTTP/1.1 should support
  everything you need. Only thing that possibly comes to mind is in
  local proxy doing maps and giving endpoint cost queries to maps then
  might want to do ????? with timestamps. for caching 1.1 should have
  everything you need. Jan Medved: I agree http interception not good
  idea but I like the draft. If becomes WG document I'd like to focus
  on ALTO server running on home gateway.

  Andrew: I confess I don't exactly understand everything here cos I
  haven't read drafts often enough. To extent need to change DNS
  packets on way back, if you're changing DNS payload you'll have
  probs. We're trying to convince people to put DNS validation on end
  points so can do DANE. So while you're trying to do something in the
  middle that will break DNS validation, I'm trying to get people to
  deploy DNS validation. Two trains on same tracks in diff directions
  - might want to be aware of that. Number of corner cases where need
  DNS lookups and they will all fail DNS validation. If you want to
  lie to DNS endpoint DNSSEC will detect that and you will fail.

  Enrico: there seems to be quite some interest in this work, but the
  transparent proxy is probably not a good idea (based on the
  discussion).


Multi-cost ALTO
---------------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Sabine Randriamasy presents multi-cost ALTO draft; Sabine presents
changes since laste version of the draft.

  Rich: is it possible to change the rule which requires numerical
  costs types for multiple costs? Sabine: no problem to make it a
  "should" instead of "must".

  Rich: to clarify if small change to increase extensibility in
  general then makes sense to have ion base protocol. If it's only for
  this the probably doesn't make sense.

  Martin: can you please clarify the reasoning for the multi-cost
  approach?

  Jon: what Martin is pointing out is app complexity that assumes, for
  diff content might want different metrics for Skype supernode might
  want something diff to download large file. Two arch approaches -
  ALTO broadcasts widest possible array and other is apps asks for
  what they want and just get that back. Bunch of ways to skin cat and
  largely whether think complexity for that decision should reside in
  the app or someone else in the network.

Sabine also presents on varying cost values, such costs could be
expressed as an array, where each entry denotes the cost value valid
during a certain time period.

  Enrico: need to warn WG there is an IPR disclosure on this draft.

  Martin: fear that this (varying cost values) becomes complex in the
  end. Sabine: that is why it should be separated from the multi-cost
  text.

  Martin: I can also do multi-cost with the standard alto protocol by
  sequentially querying for different cost types. Sabine: purpose of
  the draft is to avoid need for multiple requests.

  Rich: agree that the optimization is useful in certain cases.

  Jon: sense of room - people who think progressing with multi-cost
  work as in this draft is something we are interested in especially
  with IPR disclosure (we don't pass judgement on IPR but it factors
  into judgement to do work).

  Dave McDyson: potentially useful stuff in this draft are stoma of
  the use cases so could focus on those as ALTO finishes its work for
  rechartering activity and further discussion on what you could do
  with these. Understanding what we could do with this for
  rechartering is what I would be in favour of. Jon: you're saying
  defer consideration on this until we've done everything else? Dave:
  yes, but focus on use cases until we understand better how we might
  want to do things.

  Rich Alimi - general question for chairs. If going to consider this
  for extension drafts how should be treat other possible extensions -
  keep as individual submissions and then wait for rechartering? Jon:
  need to discuss with AD and new milestones but might not need actual
  rechartering.

  Jon: still want to get a sense on where peep are as been up a couple
  of time.

  Rich: multi-cost is probably useful & worth doing as an
  extension. Less convinced by variant costs.


Heresy time
-----------

Meeting materials: slides

External resources: audio, HTML5 video+slides+jabber

Jon presents some future directions for the ALTO WG. Maybe ALTO should
go beyond just on-demand http retrieval but also consider something
like an event-subribe model or other ways for updating and
distributing ALTO information.

  Rich: think it's a great idea.

  Martin: I second it. it's good idea.

  Dave McDyson: support for this.

  Jon: charter restricts us in some ways e.g. congestion.

  Dave McDyson: so recharter.

  Stefano: I live in Rome where heretics have hard time in past. Fully
  agree on introducing dynamics is a good thing. You mentioned some of
  the mechanisms. Does it mean have to say in that scope or is the
  heresy large enough to consider other mechanisms/encapsulations?
  Jon: I think yes, provided the mechanisms we're considering meet the
  security criteria we need to accommodate.

  Ted Hardie: two comments. If what you meant in first instance is
  XMPP pub/sub then info itself changes not at all then seems sensible
  and easy to do. But point at which you say is ALTO a proxy for
  allowing app to listen to IGP/BGP and that's much more heretical and
  far more interesting. But what you will end up doing in that case is
  change what ALTO carries to what an IGP carries to meet needs of
  timeliness. Would suggest you BOF that and spin up a WG on that
  topic using this technology.

  Wolfgang Beck: sub/notify needs state on server, will it scale? Jon:
  scalability properties of this is tough. There are presence based
  systems that are large today, e.g. Facebook. Wouldn't say it worries
  me, a lot depends where subscriptions are going to be used. If
  primary applicability is server to server scalability concerns are
  less. Whereas every bittorrent client subscribing to network map of
  universe it's different. Rich: not worried about scalability as
  subscribing to read-only thing. Can easily scale horizontally.

  Jon: heard a lot of people say cautiously it was a cool idea, don't
  have draft but maybe folks who got to microphones might want to kick
  on informal chat on it.