All,
attached are my raw(!) notes for the ALTO session and the overflow session.
Thanks,
Volker
ALTO WG Meeting Notes IETF 74
Agenda - Vijay:
- 4-5 discrete solutions for a protocol
* Discuss the mechanics here
* Discuss merits in overflow session
Problem Statement - Eric
- out for 3/4 year, stable
- no discussion on the list
Vijay: this chartered item
-> hum: adopt draft? result: good consensus
??: none of the drafts appear of the WG list
* put all alto documents on the Web page?
Jon: intentionally so
Cullen: only WG drafts appear on list/web page
Requirements - Sebastian
- changes:
* terminology updated
* reqiremnets about alto client protcol
* removed too specific itesm
- sec 4 + 5 new
- section 2: framework architecture
- subscrion of requirements "compliance"
* should there only be one client protocol or should wording say any
client protocol should comply?
Jon: should/can there be multiple protocols
Lisa:
Jon: assume to converge on one protocol but who knows
??: Maybe be another protocol in future
- requirements for error handling/overload protection
- Lars: client protocol must use TCP
- server should be able to tell clients they are overloaded
Anja: must use TCP in error case or always TCP
Sebastian: always TCP requested by transport area
Anja: there are usecases for UDP
Martin: UDP should not be regarded as transport protcol. Have very
good reasons for not useing TCP. Does not see the reasons.
Anja: TCP 3-way handshake is overhead
Sebastian: take this offlien
- discovery
- missing: how does a third party server find alto server on behalf
of a distant resource consumer
- security
- host location attributes
- client needs to have a way to express client
- how to move forward: wg should define initial set of attributes.
- define registry: register future attributes
- existing drafts contain 3 types: CIDR, AS, Group ID
- question: how likely is it to come up with additional ids
Ted: will need more. AS has many things in a routing system. If
someone wants exhaustive list should be able to do so.
Ted: mapping group id protocol is same as alto protocol?
Sebastian: yes. Mapping protocol can be a macro
Ted: without a mapping server values are useless
Seb: inside protocol specification define groups
Ted: requirements for mapping protocol should belong in protocols
specification
??: AS number is not suefule without knowing what it means to
you. Need to add attributes.
Stanislav: protocol should extensible. Should be obvious how to add
infos. No need to define exhaustive list. Just list to get started
with.
Richard: Important to have flexible IDs. Need flexibility here.
- rating crieteria
- server expresses recommendation.
- List of rating criteria that have been proposed. Initial list.
- Cleaned up document
- Next steps?
Lisa: do not publish it soon. Things that seem reasonable may turn
out to be difficult. Keep it editable.
Sebastian: is this right level of abstraction
??: multiple protocols will not help WG. Having new versions seems
ok but not having multple protocols.
Dave: requirements statement has challenge to distinguish
between what and how. This is the case here. TCP is how. What are
the decisions for TCP? What are the desires - then make decision on
what meets desires. Similarly criteria list is not is not
requirement. Instead say there needs to be an extensible critaria
list.
Stanislav: reqiurements should be wg document but should remain
editable. Enables us to change requirements if needed.
Jon: would this be a good baseline to start with? Is there another
req document?
-> hum: take this doc a wg item? good consensus.
Vijay: has more slides to present
- Activity on alto drafts:
- lots of drafts before the deadline.
- submit throughout the cycle!
ALTO P4P Protocol: Richard
- merged P4P/Info export
- objective: basic concept
- provide info to p2p apps to provide better service
- info to client and tracker
- my internt view
- network location plus cost
- alto query response defined in simple way
- query: set of source, set of destination, cost type
- response: numerical values/ranking
Martin: why mumerical and ordinal
Richard: need this: 2nd can be almost as good as first or very bad
- architectural issues
- how to specify sets of source and estination
- privacy,
- source/detination grouping
- source group: locations with similar alto costs from other locations
- destination:
- view: support aggregation
- gropuing benefits
- improves scalability
- helps privacy (masquerading)
- key design features
- instantion of proposed architecture
- transport based on http
- availability,
- decouple from htto: evolve independently
- ALTO Network Information: the interfaces
- get network map, cost map
- Inerface Descriptior
- alto response may spicyf a rule
- Example
- clients gets information and can cache it
- Example 2:
- alto client in p2p client
- iterface description returns info for pid1
- client gets info for pid1
Comparison
- 6 attributes
- lots of similarities
- there are differences
- come back to this slide at the end
Proxidor - Stefano
- Intro
- Merger of 3 proposals plus 3 implementations
- Protocol is similar even though there were differences in
algorithms
- Model: client/server
- client in p2p app or other component, server:
alto server based on ranking, servers can act as client to communicate
btw. servers)
- Messaging
- All protocols based on TLV enconding
- flexible, simple, extensible
- Query/response based protocol
- Messaging - content
- PSL: proxidor source list
- PTL: proxidor target list
- Ranking System
- Ranking system based on: topo info, policies, resource util
- Sources: routing databases, extensible to resource-state, app
network state, ...
- P2P neighbor selection:
- client sends list of notential neighbors
- server ranks list of IP addresses based on ranking criteria
- Summary
- Next step:
- we already have multiple implementations
- difficult do include all requirements into one protocol
- need to come to agreement on basic et of protocols
- then work on extensions as needed for apps
Stanislav: p2p clients are not going to send ip lists to a server.
Vijay: will be discussed in overflow session.
Stefano: reality - there are apps that do this.
Proxidor Use Case - Anja
- Legal p2p apps deployed will send lists to server
- server features:
- scaleable architecture (multithreaded
- two levels: internal vs. external topology
- Implementation
- Performance study:
- external routes: 67000, ...
- Minimal memory requirements, 4 threads: 27000 requests for seconds,
- Packet loss: less than 0.4%
Richard: pplive: 2-8 million requests per second. Lots of systems to
support this.
Anja: these numbers are across ISPs not for a single ISP
H1/H2 - Martin
- Purpose of H1H2/H12 drafts
- no real protocol yet
- describe information models
- Where we are
- Players in space: users, trackers, p2p software vendors, network operators
- not all are present here: may limit view
- H is for Hemispheres
- H1: p2p apps
- H2: netowrk operators
- How to bring them together
- Communication Model
- Client Server
- H1 Model
- Request: no info, Response: generic guidance
- H2 Model
- Request: some info (e.g. client list), response: ranked list
- H1/H2 server client model
- client cna staty his way of operating
- server replies with accepted set
- does not solve problem
- H12 model
- client sends some info (IP address, prefix, ...) that it likes to disclose
- server replies with specific guidance: answer can be 1:1 for
request, can be broad or can be narrow
- Conclusion
- each side can tune level of detail
Ted: H12 model: allocated IP address space e.g. v6
Presume: can you use record route to use .. Info hiding seems
to be broken
Martin:
Q2: yes you can always use traceroute to find out
Q1: IP addresses are one example - we're just trying to get this going
Service Protocol for ALTO - Saumitra
- Goals: look at ISP and peer performance
- provide apps with info to perform better
- info needed to assist peer selection
- common framework for info exchange
- Entities in ALTO system
- ALTO service providers, ALTO Clients, ALTO Aggregators
- Assumption
- protocols opverats over single interface
- Discovery
- get config document from an ALTO server
- Use out of band mechanism: eg. DNS SRV,
- Config Document
- xml doc
- e.g. what metric is supported: latency, distance, bandwidth
- Config Doc
- which metricts should be standardized
- should be extensible
- Message Format
- Message Context
- LocationQuery, LocationResponse
- Host Location Attribute
IPv4, IPv6 address, ...
- Guidance Query
- source hla, precision needed, metrics, list of destinations
- Guidance Qury
- object id
- Response
- List of metrics
- Example use
- Lots of synergies with Richards proposal
Server Discovery - Yu-Shun Wang
- ALTO Discofery
- Survey field and evaluate requirements against available solutions
- Discovery Metrics
- We stay at high level
- Once we progress we get to more details
- Who is doing disovery: peers, trackers,..
- Service Deployments
- ISP centric, application level, trusted third parties
- not all clients are in local network
- Single server or distributed service. Does not matter - user
rendezvous point
- DHCP
- happens during attachment
- does not work for tracker based discovery
- NAT box needs to relay info
- DNS
- well know name/port or SRV record
- need to know name (pre-discover domain anme)
- Multicast
- NAT box
speaker change -> Habing Song
- Disvoery by Peer (DHCP & DNS)
- DHCP to retrieve service name of ALTO service
- Use DNS SRV query for address information
- Discovery by Tracker
- get ISP/AS info of its clients (e.g. IANA database)
- tracker sends DNS SRV query to retrieve address info of alto
server for client
- Manual configuration
- Serve info
- Concerns
- Load balancing
- Wll known port
- IP cange of ALTO servers
- Next steps
- merged Id
- ??: pros and cons slide of DHCP slide:
- ??: look at work in geopriv - need to look into this in more depth
- Jon: lots of work has been done
- Lisa: discovery is a big problem, resource and service discovery are
different, app area presentations, all easy
- ?? look into composite approaches, evaluate methods
- Jon: is this a promising direction
- ??: architectural question: query response protocol. But topology
changes and link goes down. Nothing in the reqs about
notifications. What are the implications about this. Is this a
discussion for now.
- Jon: not a discovery question. Nothing an avalance restart in
requ. Take question offline
- Eric Hammer?: Separate between ow you find a location and how you
describe service
P2P Localization by Alias Tracker ATTP - Yunfei Zhang
- P2P apps > 50% traffic in China
- Problems
- low performance ,...
- ISP Cooperation betwen ISP and P2P poivder
- how to use topology
- prefer P2P apps sending ip addresses and return a response
- Advantage of 2nd option
- operator independece and privacy
- full use of operatofs knowledge
- no burden for p2p apps
- Vijay: context - no protocol but in solution space
- ATTP
- Alias tracker controlled by ISP cooperates with org tracker
- resource website publishes popular resource info
- ATTP Process
- peer list
- Strategies of Alias Tracker choosing seed nodes
- select according to network conditions.
- according to seed node cpapbilities
- according to peering and economic relationship
- Conclusion
- specify tracker cooperative mechanism between ISP and service
providers
- Next Steps
- Interface between local and org tracker
- application agnostic solutions
- Problems in current scope of ALTO
- local tracker and org traker interface, caches
- Stanislav: are you replicating an external website with torrents and are
reording torrents?
- Yunfei: org tracker replaced by inner tracker
Overflow meeting
Intro - Vijay
Information disclosure
- P2P vs ISP related
- converge to something in the middle?
- Jon: let the room decide
Jon: IETF has long history - something is going on in industry,
research. What do we do? Do we need a protocol. Traditional case for
this: XMPP 9 different proposals for applications. Consolidated to 3,
2 WGs. Is this the right/best outcome? Maybe not but better than we
started.
Only tool to common protocol is consenus. H12 stuff is similar to
proposal trying to reach consensus. It is up to us to agree on a set
of common elements in these protocols.
Stefano: understand the scope. Agree on protocol and not solution?
Hope protocol will accomodate all solutions we currently have. May not
need to find something in the middle. Is this against the charter of
the working group. Should we have a protocol that is flexible enough
to accomodate different approaches.
Vijay: charter is a protocol. From an implementation point of view
Stefano: protocol or solution
Vijay: issue is negotiation
Stefano: we have this in all protocols
XXcisco: H12 presentation was right on target. Can identify large oval or
small point in middle. Like H12.
If you don't reconcile this you end up in a deadlock. Be careful that
we do not often end in cases where there is no overlap. Look at
proposals at end of spectrum. H12 allows server to transform
information.
Anja: all of it is not limited to P2P. Applies to anything where
content/anything available at multiple locations. Even if a protcol
offers full info disclosure.
Jon:
Stanislav: everyone should speak for their own solutions. Are you speaking
for service providers.
Richard: WE have a problem of sorting - that will preserve
privacy. This is not true.
XX: if you use P2P client you can't keep your pres secret.
Stanislav: P2P does not
Anja: cannot be true.
Stanislav: ISP tyipcal to know who you connected to but does not know about
all peers you know about. That's the interesting part.
XX: valid point
Richard: look into what we can find out if we do ranking. Telling
information piecewise does not lead to privacy.
Anja: ranking is the minimal amount you can return. We do not claim it
is accurate. There are counter measures to make breaking security
difficult.
Question is here: benefit is only happen if both do share a little bit
of information.
Stanislav: statement if you answer orancle ranking questions often enough
cyou cna find out the underying mechanism.
M.: you can always use network tomography.
XX: User may large number of queries to lear topologies. That is a
theoretical concern.
Stanislav: not my concern
Anja: may ways to reverse engineer topology.
Stanislav: yes. the ISP knows what exactly is disclosed. The file contains
that. E.g. stay in local AS. If you answer arbitrary question you
don't know whayt you disclose.
Anja: dealing with large quatities of traffic. May want to do load
balancing, adjust dynamically. Is impossible wit ha file.
S: don't have to give everyone the same fiel.
Jon: What is the reconcilabel middleground. Is the application is any
good if none is giving info.
M.: like myinternet view. Client can ask for everything but server
only returns fraction.
Jon: there is a protocol that does some good. To what degree does the
protocol have to capture the policy asusmption. Does the protocol need
a given sharing model?
XX: Concern there is a deadlock issue. You can implement a protocol on
both ends and there is a benefit. If no P2P client / ISP participat in
each other there is no beneift. Protocol should be able to express
things in both proposals. Converge if possible
XX: allow protocol that goes across spectrum.
Stanislav: ISP may have contractual obligation not to disclose. Can be less
than foo info about everything that can be useful to disclose. E.g. I
like you to stay in ISP.
Jon: do you object to standardize a protocol that is on other end.
Stanislav: question for users. What will users perceive. In perspection of
users protocol snoops on their activites. If there is a protocol
capable of that - is this an issue?
XX: You can't speak of all BT users. I can't speak of all
ISPs. Argument in favor for an expansive protocol.
Anja: differnet kinds of applications. Solution may depend on
application. We shouldn't expclude on or the other.
Jon: who objects to doing one or the other end? Nobody.
Jon: do you think ISP end is defeating the protocol.
Stanislav: don't know.
Jon: protocol had capability but implementer can set threshold on what
is disclosed. Would this be a problem in community. Just the fact that
protocol has capability?
stanislav: jsut question of perception.
M.: purpose of H12 protocol.
Jon: tons of protocols with various capabilities misunderstood in the
press. Always a risk.
YY: Draw a line where the privacy bar should be? The more info yyou
are willing to disclose the better the service by ALTO. We don't know
how much info each user is willing to disclose. People make these
choices. Have to allow users to make these decision.
Stanislav: users are fine with performance today. ISPs are unhappy.
YY: You may get lower cost for your performance.
Anja: your app use network resources inefficiently. You can get better
performance from local transfer.
M.: a service provider offers flat rate as long as stays within
network but 10G to other ISPs. Flat at night.
Stanislav: how do you know as a user.
Anja: by querying an alto server
Stanislav: but a ranking isn't goingto help with this.
Richard W.: Three stakeholders: network, app, user. User paranoid about his
info. App about getting infos. App can choose
Anja: question is which service will ISP offer
Richard W.: offer separate service.
XX: Mechanism that helps application and net to converge. Maybe that
is differential pricing. Many different incentives at play. Protocol
designers enable mechanism to converge.
Richard W.: conversion is good. Will there be users that this the app is
giving away to much info.
Anja: chart is messed up! :)
Anja: bubble 1 - if no user can be forced to user alto server. Privacy
concerned users can be turend off.
Stanislav: will be off by default.
YY: there is performance improvement. Learning process is
individual. Share information so that each peer can learn from
experience of others. I.e. sharing information.
Richard: 1 is good for ISP. Ranking look at all perspective. Network
privacy. We do an analysis.
Anja: can be countered.
Richard: privacy bad for app and ISP
Analyze performance. 1 has scalability issues for servers. Each
request send to servers all the time. Very frequent hits. Bad for
performance.
App performance analysis. Ranking does not provide app
performance. Optimizing logic that
Anja: BT is just one possible app. Show that ranking can imporve perf.
Jon: need to know what protocol wants to do. How use protocol.
Can find virtues and flaws in boths ends.
Acceptable - have a protocol that covers both ends
Richard: Ranking supported by our proposal. But seems the last
protocol to use.
Jon: client might decide what to use. Can we allow for the superset of
this.
Richard: not buying performance impr.
Jon: need to go.
XX: do consenus call.
- Hum: Try to define a protocol that supports the full range of picture.
good consnsus.
Critical for mechanism to reach conclusion of what to do. Do people
support convergence.
Jon: trying multiple time
XX: does not lead to deadlock
Jon:
- hum: who supports some kind of negotiation mechansm
leaning toward negative
Vijay: one more presentation:
DNS based IP netlocation service
Question: are you using static DNS record
Have to figure out ... ??
Q2: how many users does chinatelecom have.
Vijay: discussion on the list
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
