IETF81 - P2PRG Meeting Agenda
=============================

10 min - Agenda bash, status update etc. (chairs)
* See Chair Slides
* Ready for Publication
- mythbustering (needs refresh), experiments-japan
* Issue with mythbustering, should presentation by Moritz be included?
* Volker Hilt (VH): has been stable, need to publish.
* Enrico (co-author): proposed to include this in the refresh

* Stefano Previdi (SP): Need more active research group review of
cross-domain-overlay
- If you are interested to perform and publish a review to the p2prg
list, contact volker and stefano

* Two new drafts:
- Simulation survey (Vijay)
- Research P2P video streaming systems (Moritz)

20 min - Update on: draft-asai-cross-domain-overlay (Hirochika Asai(HA)

Dave McDysan (DM): Does case in slide 3 occur frequently? A: Occurs in
some cases, e.g., local ISP, regional ISP, national ISP, global ISP.
Lars Eggert: Will the relationships shown on slide 3 be persistent or
transient? alto will not magically create a completely different set of
connections.
DM: Slide 14 - Degree of "goodness" is amount of traffic directly from
customers, which requires transition of fewer AS hops.
Piotr Wydrych (PW): Slide 5 - Alto servers in ASes can communicate with
each other to combine results and solve this problem. To be presented in
alto session today.
<http://tools.ietf.org/html/draft-dulinski-alto-inter-problem-statement-01


Richard Alimi (RA): In event of conflict, who decides who loses? Someone
will be unhappy. A: Difficult.
SP: Intent is to replicate what would happen in network layer. Global cost
map is a result of mapping of network policy to the alto cost map.
PW: Adding costs not always sufficient. OK for Bittorrent, but not
sufficient for upload/download.
SP: Nothing prevents having multiple alto cost maps, which represent
different things.
VH: Question to PW. Does inter-alto protocol solve a similar problem? A:
Yes, but draft right now focuses on the problem statement.
VH: Suggested that PW and HA collaborate since they appear to be
addressing a similar problem.
VH: Need to ensure that problem is clearly stated. Solution should go to
the alto wg.
Vijay Gurbani (VG): Agreed with VH recommendation.

30 min - draft-gurbani-p2prg-simulation-survey (Vijay Gurbani (VG))
VG: Plan to release -01 soon.
VG: Asked for survey participation (slide 9)
http://goo.gl/zTCKO

VH: Questioned survey methodology of choosing broadest option -- people
will ask for everything. What is the tradeoff between what will the user
actually use, develop versus what they might like to have. VG: Tried to
address by soliciting preferences (e.g., number of nodes supported).
VG: Asked for input on other simulators not listed on slide 16.


30 min - DHT-based P2P Traffic Localization (Moritz Steiner(MS)
SP: Received ANRP Prize.
- Include a citation for the paper
* Numbers come DHTs implemented by the various networks
* Network-based approach versus client-network collaboration as in alto
VH: Slide 9, implementing a tracker would only benefit a smaller fraction
of users represented by the blue line.
MS: Agreed. Note that DHT is normally faster than the tracker and it is
used.
??: A small fraction of peers learned from tracker, and is almost
irrelevant today.
VH: alto in the client to communicate with a server is fine, but alto in
the tracker will have less benefit.
MS: Need to retrieve a large number of peers and then filter. Would be
better if the discovery process did filtering and delivered a usable
number of peers.
??: Slide 12 could be viewed as an attack on the DHT.
RA: In at least one DHT (Vuze) nodes cache previously received responses.
Would Sybils be injected at multiple nodes.
VG: Don't have authoritative information about peering partner.
??: DHT implementation that uses density of peers around a given hash may
complicate use of this approach.
MS: Agreed, would need something different. All based on linear with no
security methods.
RA: Has this been compared to VUZE client to concatenate title and AS and
insert into DHT. 
MS: Would require modifying the client. Depends on client adoption.
VH: RA's comment is client modification in taxonomy.
** Demo
- 16 Sybils are running on a Linux machine in Lucent data center in Chicago
- Windows machine running FiOS and uTorrent
Rich Woundy (RW): How is ISP determined? : Determined by uTorrent (Reverse
DNS lookup), Sybils use Maxmind database. In example of slide 19,
geography within US is not known.
MS: Yes, possible to localize within the ISP.
??: Very easy for someone to manipulate the DHT.
MS: Agreed. Also it is difficult to bring down a tracker.
MS: Not much eMule only adds a few peers from the same subnet.
SP: alto architecture relies on collaboration.
Arnno Bakker (AB): Not allowed to choose your own ID in DHT -- difficult
to enforce.
MS: Actually Azeurus enforces this.
MS: Slide 29 - PEX has little impact since DHT is faster.
Bjore Ohlman (sp): Looked at structure DHT in hierarchies (e.g., per ISP)?
MS: Yes, showed a demo like this in Infocomm with 2 levels: per ISP and
everything. Requires change to clients.
RA: What is biggest barrier to changing clients? Rolling out updates,
changing clients?
MS: Opensource projects - difficult to move in a strong direction. P2P
client providers may not have incentive.
RA: uTorrent, VUZE have regular updates. In P4P investigation VUZE was
cooperative.

30 min - A Survey on Peer-to-Peer Video Streaming Systems (MS)
* Authors agreed to update cited paper with MS.
Richard Yang: In China ISPs are not well connected, and hence latency
drives to localization. Could be a different situation in Europe.
Live streaming don't pick low latency peers, but use a complex algorithm
to pick peers. Would be good to clarify this point.