Re: [p2pi] why i hummed no

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou at alcatel-lucent.be>]

I share the concern that the statement part of the charter discussion
"Discovery mechanism for locating the oracle - Query/Response protocol
for communicating with the oracle" combined with the objective listed in
the PS doc. "...to choose the best endpoint among those which host a
desired resource." induces - unconditional localisation - as it does not
consider the issue of combining perf. obj. x cost. obj. from both ISP
and host/APP side. It is exactly the reasoning I have tried to outline
also by underlining the challenge of best path selection (what Bob
referred to as the "policy-controlled path-selection advice"). In a
sense, using the so-called oracle for best-end point selection only is
not going to deliver the expected/satisfactory outcome for all parties
at stakes in this effort.

-d.

> -----Original Message-----
> From: p2pi-bounces at ietf.org [mailto:p2pi-bounces at ietf.org] On 
> Behalf Of Bob Briscoe
> Sent: Wednesday, July 30, 2008 9:28 PM
> To: Enrico Marocco
> Cc: p2pi at ietf.org
> Subject: Re: [p2pi] why i hummed no
> 
> Enrico,
> 
> I am well aware there were sensible people in the 
> room who know the problem isn't localisation (see 
> my preceding mail on procedural rather than issues with the ALTO BoF).
> 
> However, those who stated it as a solely 
> localisation problem had the floor exclusively on 
> Tuesday. That was a signal to me that any future 
> ALTO w-g will have to continue to deal with this 
> high percentage of low cluefulness among those working on this issue.
> 
> I'm not worried that you don't understand it. I'm 
> worried we can't get others to understand this point.
> 
> 
> Bob
> 
> 
> At 15:09 30/07/2008, Enrico Marocco wrote:
> >Bob, ALTO is not about "localization" only (which, btw, is quite an
> >ambiguous term, best avoided). Probably we have not made it clear
> >enough, but AFAIR network policies are always mentioned 
> amongst possible
> >criteria to rank peers.
> >
> >Anyway, thank you for your contribution, it will help people in
> >understanding the problem are and hopefully will foster some 
> discussion.
> >
> >Enrico
> >
> >Bob Briscoe wrote:
> > > Folks,
> > >
> > > Following my last mail on procedural reasons, here's my 
> technical reasons.
> > >
> > > Technical
> > > ---------
> > > I've drawn a picture (very simplified), as I think some 
> people wanted to
> > > have a better model of what commercial residential 
> networks look like.
> > > <
> > > 
> > 
> http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807
> alto-briscoe.pdf
> > >>
> > > Text in the above slideset is repeated below, numbered by slide...
> > >
> > > 2. Localisation is NOT consistently desirable
> > > ------------------------------------------
> > > whether by AS count, hop count, RTT, ...
> > >
> > > * for ISPs (slide #3)
> > > -using an interconnect path may impact other users less 
> and not cost the
> > > ISP more
> > >   a)upstream backhaul link
> > >   o in some access technologies (e.g DSL) the upstream 
> backhaul is never
> > > congested - it's typically a symmetric link fed by an 
> asymmetric access
> > >   o retail ISPs often lease this link without any 
> upstream usage penalties
> > >
> > >   b)interconnect
> > >   o if interconnect charging is based on 95th percentile and it's
> > > currently not near the 95th percentile
> > >   o or if interconnect is based on a peering contract which only
> > > requires the balance of volume transferred between networks to be
> > > checked at peak times, and it's currently not a peak time
> > >
> > > * For users & apps (slide #4)
> > >   o with newer cc algos, longer RTT hardly requires slower rate
> > >   o desire for shorter RTT to get higher rate will go away
> > >
> > > 3. ISPs could prefer inter-domain path
> > > --------------------------------------
> > > <picture> - see slide
> > >
> > > 4. Lower RTT isn't nearly as good as we thought
> > > -----------------------------------------------
> > > for long-lived flows
> > >
> > > * app desire for localisation is artefact of TCP algo
> > >   - TCP average rate depends on 1/RTT (for similarly 
> congested paths)
> > > * modern congestion control algos don't do this
> > >   - FAST TCP [Jin04], BitTorrent DNA (rate-based mode)
> > > * for stability, doesn't rate need to depend on 1/RTT?
> > >   - No. Research agrees only /acceleration /needs to
> > >   - Equilibrium rate can be independent of RTT
> > >   (see slide #4 for a typical example)
> > >
> > > 5. What metric judges 'better'?
> > > -------------------------------
> > > * NOT lower inter-domain traffic (necessarily)
> > >   - if at the cost of more local upstream congestion
> > > * NOT faster downloads (necessarily)
> > >   - if at the expense of slower downloads for non-P2P users
> > >
> > > 6. closing message
> > > ------------------
> > > * localisation is only desirable conditionally
> > >   - over some inter-domain paths, at some times, with 
> some transports
> > > * updating an inter-domain oracle for dynamic 
> path-specific info is not
> > > proven feasible
> > >   - hard even for a single residential ISP
> > >     -e.g. 20M access lines =>  20M2 paths 
> (400,000,000,000,000 paths)
> > >     -and that doesn't include home network segments
> > >     -even edge-edge, 7,000 access multiplexers => 50M paths
> > >   - for inter-domain oracles, 100M muxes => 
> 100,000,000,000,000,000
> > > edge-edge paths
> > > * nonetheless, topology-based heuristics modified by 
> static policy (e.g.
> > > P4P) are perhaps 'better' than random guesses
> > > * but "localisation is good" MUST NOT be the goal
> > >   - that will lead to the DISINTERNET
> > > * localisation would be easy,... but if it's NOT the goal
> > >   - is an oracle appropriate for standards activity or 
> only for more
> > > research?
> > >
> > > Cheers
> > >
> > >
> > > Bob
> >
> >
> >
> 
> ______________________________________________________________
> ______________
> Bob Briscoe, <bob.briscoe at bt.com>      Networks Research 
> Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    
> +44 1473 645196 
> 
> 
> _______________________________________________
> p2pi mailing list
> p2pi at ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
> 
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi