Subject: Re: [p2pi] why i hummed no

From: Bob Briscoe <[email-masked]>
Date: Wed, 30 Jul 2008 14:42:43 +0100

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, <[email-masked]>
Networks Research Centre, BT Research

B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5
3RE,UK.    +44 1473 645196

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 30 Jul 2008 06:53:08 -0700

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" <[email-masked]> 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.pd
> f> >
> Text in the above slideset is repeated below, numbered by slide...
> 
> –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
> 
>   - TCP average rate depends on 1/RTT (for similarly congested paths)
>   - 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
>     –e.g. 20M access lines =>  20M2 paths (400,000,000,000,000 paths)
>     –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
>   - is an oracle appropriate for standards activity or only for more research?
> 
> Cheers
> 
> 
> Bob
> 
> 
> Bob Briscoe, <[email-masked]>     Networks Research Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196
>

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 30 Jul 2008 15:09:37 +0100

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:
> have a better model of what commercial residential networks look like.
> <
> requires the balance of volume transferred between networks to be
> checked at peak times, and it's currently not a peak time
> 
>   - No. Research agrees only /acceleration /needs to
>   - for inter-domain oracles, 100M muxes => 100,000,000,000,000,000
> edge-edge paths

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 30 Jul 2008 20:18:52 +0100

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"
<[email-masked]>
wrote:

Folks,

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>

* 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

b)interconnect

o if interconnect charging is based on 95th percentile and
it's currently not near the 95th percentile

o with newer cc algos, longer RTT hardly requires slower
rate

o desire for shorter RTT to get higher rate will go
away

<picture> - see slide

for long-lived flows

- if at the expense of slower downloads for non-P2P
users

6. closing message

------------------

* updating an inter-domain oracle for dynamic path-specific info is
not proven feasible

ˆ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

* nonetheless, topology-based heuristics modified by static policy
(e.g. P4P) are perhaps 'better' than random guesses

- is an oracle appropriate for standards activity or only for
more research?

Cheers

Bob

Bob Briscoe,
<[email-masked]

p2pi mailing list

[email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 30 Jul 2008 20:27:49 +0100

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:
> > using an interconnect path may impact other users less and not cost the
> > ISP more
> >   a)upstream backhaul link
> > congested  it's typically a symmetric link fed by an asymmetric access
> >     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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 31 Jul 2008 12:25:37 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Briscoe
> Sent: Wednesday, July 30, 2008 9:28 PM
> To: Enrico Marocco
> Cc: [email-masked]
> Subject: Re: [p2pi] why i hummed no
> 
> Enrico,
> 
> > > -using an interconnect path may impact other users less 
> and not cost the
> > > ISP more
> > >   a)upstream backhaul link
> > > congested - it's typically a symmetric link fed by an 
> asymmetric access
> > >     -e.g. 20M access lines =>  20M2 paths 
> > >     -and that doesn't include home network segments
> > >     -even edge-edge, 7,000 access multiplexers => 50M paths