Subject: [alto] IETF 73 ALTO notes

From: Volker Hilt <[email-masked]>
Date: Wed, 26 Nov 2008 00:00:28 -0500

Attached are my notes from the ALTO meeting in Minneapolis.

Volker
ALTO WG Meeting Notes – IETF 73

1:05 Agenda discussion (Vijay)
No comments

1:06 WG Status (Lisa)
- Work was initiated at MIT workshop
- Understand technical problems, constraints.
- Outcome of workshop: two BoFs (ALTO/TANA)
- P2Pi mailing list work on ALTO charter – is narrow and well scoped
- Make better than random selection decisions
- Work on technically and organizationally feasible problems
- Come up with feasible schemas
- P2P RG in IRTF 
  o E.g. P2P pricing, getting information from routers, etc.
  o If WG is not certain about something go to RG
- WG chartered a couple of weeks ago
- ALTO service can come from any different places (not only ISP)
- Vijay, Enrico, Jon will be WG chairs

1:11 IRTF P2P RG (Aaron)
- Effort P2P RG to re-charter 
- Charter created by Stefano and Volker
- New charter has been submitted
- Covers broad range of topics
- Wiki on more specific topics
- Model: IRTF partner with WG in IETF – things that are not baked for standardization sent to IRTF to come back to IETF
Vijay: talk to us if there are topics for the IRTF RG

1:15 ALTO Problem Statement (Enrico)
- Reflects all comments and feedback from Dublin
- Main benefits: improve performance, optimize network resources
- Changes:
  o Do better than random (not optimal)
  o Optimization may be localization but can also be something else (depending on topology)
  o Replaced term oracle
  o New terminology section
  o Added solution consideration section
Jon: Is this going into the right direction
??: Do not have the solutions consideration as part of the problem definition
- The WG hasn’t had a discussion of the solution space.
- Privacy: clients may optionally use this service - can’t force the use of the information.
Enrico: this is voluntary no-one forces ALTO
??: who determines what is private and what is acceptable – can’t make this a generic call. 
Enrico: We shouldn’t say…

1:26 Requirements (Sebastian)
- Changes: 
  o Aligned terminology with terminology draft
  o Changes to reflect comments on ML and Dublin
  o Remove implicit assumption of sorting oracle style solution (former Req 5)
  o TBD: section on overload control. Clients may not send queries very often – possibly overengineered
  o Question about UPD vs. TCP
- Next steps: three approaches (sorting oracle, info export, P2P)
  o All fulfill requirements
  o Some requirements for specific approaches
  o Build framework or build upon existing proposals
  o Goal: definition of core set of attributes that is extensible
  o More simulations and field tests needed
  o Optimize for app and network performance
Leslie: Specific requirements for transport protocol. Is XML over HTTP ok? No requirements?
Sebastian: No requirements for HTTP etc.
Leslie: Will there be such requirements
??: This is individual document. What is the point of the discussion?
Jon: Not uncommon to propose individual document
??: Backup slides are the ones that should be presented. The WG has not been alerted about the draft. No discussion on this about the mailing list. 
Jon: Who has read draft? Quite a number of people have.
??: Is there assumption on agreement on draft
Jon: Doc does not have WG status
Hannes: Time on requirements documents is wasted time. Important are solution discussions. Can’t treat requirements separate from solution. Group should build solution.
??: Document needs some work. Lots of things are implicit. E.g. overload mechanism: dropping messages places implicit requirements on transport protocol which is not good. Consider real requirements of transport protocols. Make all requirements explicit.
Sebastian: Due to history – draft assumed a specific solution. Let’s postpone discussion until we know more.
Dave: Interesting topic. Good that there is attempt to make progress. But there needs to be effort that people are in sync. Concerns about having 1st meeting talking about deltas. Culture everyone to basic requirements. Requirements get our heads in wrong place. Too little experience. Actually only few people read and understood and discussed it. Rethink how to approach.
Jon: Need to come to common understanding. Need to do that.
??: Requirements documents just structure problem but don’t give it authority. 
Hannes: These requirements don’t provide any additional help to reader – basic requirements. What are the really challenging aspects – usually 3-5. Consider architecture
??: Difficulty is to define the problem to be solved. Requirements fall out once you understand the problem.
Jon: Requirements may not be entirely helpful. 
Vijay: Raise hands – who has been in MIT workshop (couple). Most important question: how can you be more specific. Give requirements more teeth. Now we have deployments – authors should talk to these people – what are their requirements.
Dary: Like requirements docs – helps to frame the immediate needs of WG. People will want add-ons and solution will be delayed. Vendors will do own solutions. Agree on set of immediate requirements. Avoids creep.
Stanislav: Sequencing of work. Requirements should be done before or with solution. Iterate between requirements and solutions. 
Jon: More discussion needed of this document. Maybe need to do a tutorial.

1:48 P4P (Richard Y.)
- Talk about one possible solution
- Service to help with peer selection. 
- What service is needed: location and distance portal service
- Location portal service: allows isp to aggregate address space
- PID: defines set of network locations
  o Does not use standard terms: privacy  (ISPs don’t want to reveal specifics), not flexible enough (AS, POP, …?) 
- Implications: GetPID, GetPIDMap
- PID for 2 reasons: efficiency, will not be sent to ISPs
??: Does each ISP have to define own PIDs
Richard: Each isp defines own view on PID
??: Prefix aggregation may not work
Richard: Yes. This is a trade off 
??: One AS is assigned to 16 but for TE purposes the part is turned over to someone else. AS would have to disaggregate announcement. Some of the announcement routes are only true if you know the hole punching routes of someone else.
Richard: … You can do TE
??: You will need full routing table
Anja: Who will use service
Richard: App trackers and applications. 
- pDistance portal service
- 2 semantic: ordinal or numeric
- Recommend: numerical distance
- Example
- Interface: getpdistance: location – output pdistance value
- Two interfaces: location and distance
??: Would be valuable to see if results from server and results from looking glasses would be the same. If not why not. Ask looking glass maintainers.
Richards: Should also talk to ISPs.

2:02 Comast Experience (Richard W.)
- Testing this summer with p4p
- Optimize P2P traffic in a way that is in collaboration with p2p vendors
- Trial over cable infrastructure. 
- Key results: also in draft
  o Impoved download speeds
  o Effective in localizing traffic
  o Evidence: no increase in upstream congestion. This is important. 
  o Enough merits to keep going on with this. Work with Richard Y. on next tests.
- P4P Overview
  o Idea: capture enough topology information so that tracker can make intelligent decisions. Returns prioritized list to client.
- Test tracker lists. Tracker implementation. Peer exchange was on
- 20 MB file. End clients were made to download file. 5 swarms – each with different principles. 
- Operate 2 itracker. 1 really down close to the hub/transport node. Fine grained model: 11080 PIDs. Massive configuration. Course grained: 22 PIDs. Generic – course with simplified calculation. 
- Ran over summer
- Results. Big improvements on Comcast average. Can’t explain why course grained is better than fine grained. 
??: Justification for non-intuitive results? 
- Reduction on policy informed decisions.
- Reduction on ingress traffic 80% - real money slide
- Usually more traffic coming in than going out. Interesting savings.
- Next Steps: more testing, more vendors, streaming, larger files, … 
  o Think there is some truth
  o Does not solve last mile problem. Will transit saving give customer a better experience
  o Unmanaged p2p traffic 
??: Does Pando schema use P4P technology. 
Richard: No but acts in similar way. 
??: comparable to use P4P
Richard: Scale distribution of information. 
??: Did you compare to other peer selection strategies (other than random). 
Richard: Pando would have done random. Peers are randomly assigned but then 
Richard Y.: difference between course and fine grained more technical discussion

2:17 Alto export service (XX?)
- ISP prepares ALTO
- Client discovers ALTO service (out of scope). Result is HTTP(S) URL
- Client gets list of IP prefixes
- Format of information: CIDR / ASN 
- If prefix is not found – default behavior is assigned
- Peer should be able to work in the absence of alto
- Peer picks from preferred list (e.g. 50%), chose rest from the default set, last resort if not enough peers available use avoided list
- Mapping addresses to ASNs
  o Download from looking glass or alto server
- Related issues

??: Work in SIDR WG. Construction of verifiable mappings
Anja: how much info do you expect a client to download
XX: no limit to what an isp can disclose
Anja: did you want to download the routing tables? How much info does client send?
XX: client does not send any information. 
Anja: How much info would the client have to download. 
XX: up to isp
Stanislav: usually zero. This info is usually cached. Once cache is stale you get it again. Amount depends on isp. Expect around 1000 records with 50 bytes each record would give reasonable improvements.
Leslie: app area in IETF. What is the type of information? Put less emphasis on format of it (e.g. line endings etc). Generic lookup problems. Stay focused on the information that is needed. Don’t think you won’t need the complexity of existing systems. 
Richard W.: Had examples in slides. E.g. 210000 for find grained.

2:31  Routing Proximity Service (Stefano)
- What is important? 
- Implementation based on routing layer information
  o Leverage routing data information
  o Info on routing layer is well known
  o Interface to routing layer is well known
  o Routing DBs have good properties to compute localization
  o Why routing layer information
* Consistency: peer will issue request that is forwarded over the routing layer.
* Leverage routing layer: entity that has the real information. Looking glasses have some info but that may not be used by local ISP. 
* Information is available all the time and is being updated all the time. Fast convergence, re-route, etc. can be leveraged.
- What is needed
  o Alto protocol between client server that supports routing-based proximity
- References

Jon: is there a draft 
Stefano: maybe
Ruediger: routing contains lot of useful information. However, looking from operators point of view we are not usually representing available bulk capacity in routing. Don’t manage spare capacity in routing level. Probably additional relevant information that is out there. Have you thought about this information?
Stefano: We are at the beginning and are not excluding info. There may be other information on the measurement side of performance. Just investigations 
Richard W.: Topology changes. Routes are advertised/withdrawn. We want info passed to clients stay there for day/week. Would be good to have info that is smoothed out. 
Stefano: To clarify: don’t pass network info to clients. Compute proximity. Info advertised can be aggregated. Algorithms that leverage real info of infrastructure for computation is powerful.
Igor: What is meant by routing layer. Do you assume interoperation of app servers with routers? Is there intermediation system?
Stefano: Plenty of possibility. Here, agree what is the signaling needed. Come to agreement on how service is implemented. Have a solution architectured around an ALTO server.
Igor: Recommend group to look at FORCES WG. Useful information can get there.
Richard Y.: Routing metrics are different. For peer selection: question is which node is better. Not necessary based on routing metric. Sometimes other information is better.
Stefano: Don’t believe we need special configuration. Don’t convert from routing infos. We can do something elese. Routing protocols deliver what you need to have a different level of abstraction of your policy.
Anja: two different approaches: 1) give client/tracker as much as info possible 2) just give course grained info. Might want to react to changes in the network.  Info missing: congestion information.
Stefano: routing is just one source of information. 
Jon: Remember charter text on congestion

2:46 Multidimensional Peer Selection (Saumitra)
- Peer selection is applicable to various aspects of p2p 
- Define common framework
- Peer input is not enough – optimize transfer performance
- ISP input is not enough – some info needed is not available to isp. Interested in minimize congestion, interdomain traffic.
- Multidimensional ALTO
  o Service discovery
  o Publication framework
  o Query
- Design recommendations

Richard W.: Make sure all ideas make sense. Topological closeness may not make sense. 
Saumitra: There may be cases – not necessary argue for it
Stanislav: Ability to publish info to an ISP is not an incentive to apps.
??: You argue for building an interface but do not describe info at all. What information is useful? You have deferred the hard part. Will WG study.
Saumitra: Need to solve the hard part. But there may be pieces of info we don’t know about yet. 
??: build a protocol that is extensible. You are saying we should not talk about info.
Saumitra: No.
Jon: Must be at least one interesting piece of information.

Jon: General comments?
??: Alto using bandwidth? Would you pick path with most bandwidth. Provider may not want p2p traffic not to pick best link.
Saumitra: ISP will give guidance. Application can make informed choice. Should have flexibility. Bandwidth service may not be optimal. Want it to be extensible.

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto