Re: [p2pi] why i hummed no

[Reinaldo Penno <rpenno at juniper.net>]

Title: Re: [p2pi] why i hummed no

Hello Bob,

Actually I sent an email about this issue some time back and some people agreed with it. It talked about the fact that some ISPs/Telcos would prefer P2P to use inter-domain links.

Check http://www.ietf.org/mail-archive/web/p2pi/current/msg00212.html

Thanks,

Reinaldo


On 7/30/08 6:42 AM, "Bob Briscoe" <rbriscoe at jungle.bt.co.uk> 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 <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

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