Re: [p2pi] why i hummed no

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

Reinaldo,

Yup, thanks. I had read your mail.

I was just trying to be more specific. I was hiliting the many cases
where the cost of upstream congestion to an ISPs own customers is greater
than the cost of interconnect /plus/ the cost of upstream congestion to
another ISP's customers, even where both uploaders are
residential.

I also wanted to illustrate what backhaul meant for all those that had
never heard of it - given it's so important to this discussion. 


Bob

At 14:53 30/07/2008, Reinaldo Penno wrote:

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

____________________________________________________________________________
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