Re: [p2pi] why i hummed no

[Enrico Marocco <enrico.marocco at telecomitalia.it>]

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/0807alto-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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi