Re: [p2pi] why i hummed no

[Bob Briscoe <rbriscoe at jungle.bt.co.uk>]

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

____________________________________________________________________________
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