Subject: Re: [p2pi] ALTO BoF - generalize the problem

From: Laird Popkin <[email-masked]>
Date: Mon, 14 Jul 2008 17:14:51 -0400 (EDT)

P2P applications have the problem that they're told about the network's performance only on a per-stream basis, but they have to make decisions on a global basis, not just a stream basis. If the p2p app knows the user's link capacity, or preferably the link status (e.g. is it saturated?) then the app can make better choices. For example, should I try to establish more peer connections to speed data transfers, or have I saturated the user's internet access link? If the latter, may want to throttle myself in order to decongest the user's internet connection (or DSLAM, etc.) which is better for everyone.

Yes, there are scenarios where it's not clear whether there is a relevant link capacity, etc., but I'm fine getting no guidance in those situations. Even an 80% accurate knowledge of what the user's network capacity is would be a big improvement over the current situation.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "ext Salman Abdul Baset" <[email-masked]>
Cc: [email-masked]
Sent: Monday, July 14, 2008 3:22:46 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

On 2008-7-14, at 10:13, ext Salman Abdul Baset wrote:
> Obviously, measuring the path capacity or using the path is required  
> when the connection type indicates to the app that it should have  
> enough capacity.
>
> When the connection type indicates to the app that it does not have  
> enough capacity say for relaying a VoIP or video call, the  
> application does not need to measure anything. It knows that it  
> cannot do the requested work and will never advertise its relay  
> service thereby avoiding the measurement of transient available  
> capacity.

OK, so be conservative and default to off, i.e., only offer to relay  
after your network usage has left you convinced that you have capacity  
to be a relay. This should even have some benefits to the peers,  
because only nodes that have been around for a bit will become relays.

Getting this information from an oracle doesn't save you any work,  
because even if your nominal uplink capacity could let you be a relay,  
you still need to figure out if the current load on it actually lets  
you. Plus, there are obviously uplink types with no stable capacity  
(3G, WiMax, etc.) where this won't work anyway.

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 15 Jul 2008 11:03:49 +0300

Hi,

On 2008-7-15, at 0:14, ext Laird Popkin wrote:
> P2P applications have the problem that they're told about the  
> network's performance only on a per-stream basis, but they have to  
> make decisions on a global basis, not just a stream basis.

Sure, but if you're willing to assume that the access link is always  
the bottleneck, surely you can assume that all your streams go through  
that access link? That lets you infer path characteristics based on  
aggregate stream characteristics.

> If the p2p app knows the user's link capacity, or preferably the  
> link status (e.g. is it saturated?) then the app can make better  
> choices. For example, should I try to establish more peer  
> connections to speed data transfers, or have I saturated the user's  
> internet access link? If the latter, may want to throttle myself in  
> order to decongest the user's internet connection (or DSLAM, etc.)  
> which is better for everyone.

If the access is the bottleneck, and there was some way to get this  
information accurately, reliably and in a very timely fashion - maybe.  
But you're redefining the basics of Internet congestion control here,  
turning it from an approach where the ends probe the path and adapt to  
one where network-provided information drives the congestion control  
loop. That's way beyond what I'd consider appropriate for ALTO to  
tackle at this stage.

Note that I'm not saying that we should never think about this. There  
are related proposals that attempt to give the network a more active  
role in end-to-end resource control (Briscoe's re-feedback, some ideas  
by Matt Mathis, etc.) But if we do something along those lines, we  
need to think hard how this interacts with the rest of the architecture.

> Yes, there are scenarios where it's not clear whether there is a  
> relevant link capacity, etc., but I'm fine getting no guidance in  
> those situations. Even an 80% accurate knowledge of what the user's  
> network capacity is would be a big improvement over the current  
> situation.

Not without additional information. If I run five P2P apps on  
different machines in my home and they all know my access link  
capacity through some mechanism, they'll still self-interfere before  
they have ramped up to that capacity.

Lars

---

From: Laird Popkin <[email-masked]>
Date: Tue, 15 Jul 2008 07:44:36 -0400 (EDT)

Yes there are ways to try to derive link capacity, and to try to guess whether the link is saturated, but they're all (in real life) wildly inaccurate.

I agree that link capacity is of limited value, due to multiple applications interacting (and multiple computers, etc.). Link congestion status is a lot more valuable, IMO. None of this eliminates the need to do stream-level congestion management, of course. :-)

Yes, I've been tracking Re-ECN. It looks very interesting, and I hope to learn more at the IETF meeting. If it's available "in the wild" that would be great.

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "ext Laird Popkin" <[email-masked]>
Cc: [email-masked], "ext Salman Abdul Baset" <[email-masked]>
Sent: Tuesday, July 15, 2008 4:03:49 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

Hi,

Lars

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 15 Jul 2008 07:58:33 -0400 (EDT)

On Tue, 15 Jul 2008, Lars Eggert wrote:

>> Yes, there are scenarios where it's not clear whether there is a relevant 
>> link capacity, etc., but I'm fine getting no guidance in those situations. 
>> Even an 80% accurate knowledge of what the user's network capacity is would 
>> be a big improvement over the current situation.
>
> Not without additional information. If I run five P2P apps on different 
> machines in my home and they all know my access link capacity through some 
> mechanism, they'll still self-interfere before they have ramped up to that 
> capacity.
>

It seems that this is a scenario where cable/DSL modem should pass 
information of self-interference to other machines behind the same modem. 
For example, if mom/dad is using the Internet connection for work and are 
not getting the expected speed, they will like to know which child/device is 
hogging the connection.

-s

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 15 Jul 2008 14:25:06 +0200

> not getting the expected speed, they will like to know which child/device is

This discussion is certainly interesting, but it is not about ALTO any
more, is it? I mean, in this context we are trying to charter a working
group for developing some mechanism for optimizing peer selection. At
best, "network" information will be used for selecting between a peer
with FTTH access and a DSL ones, when no additional information is
available.

The TANA BoF discussed on the [email-masked] mailing list explicitly
covers transport issues like congestion notification and sharing of
network resources; its problem statement is available at:
http://tools.ietf.org/id/draft-shalunov-tana-problem-statement

-- 
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 15 Jul 2008 09:16:17 -0400 (EDT)

> with FTTH access and a DSL ones, when no additional information is

Information about self-interference can guide peer selection. For 
example, with this information, a P2PSIP application running on one of 
several machines behind the cable/DSL modem can more accurately determine 
the presence or absence of self-interference. In the absence of 
self-interference and after network usage has left the P2PSIP 
application convinced that it has enough capacity, it can advertise itself 
as a relay in the overlay.

> http://tools.ietf.org/id/draft-shalunov-tana-problem-statement

It is not clear to me whether it will/should be in the scope of ALTO or 
TANA to address the self-interference issue. Note that self-interference 
can be categorized as (1) interference with applications running on the 
*same* machine (2) interference with applications running on *different* 
machines that are behind the same cable/DSL modem.

-s

---

From: Laird Popkin <[email-masked]>
Date: Tue, 15 Jul 2008 09:41:26 -0400 (EDT)

In terms of whether this issue is more appropriate in TANA or ALTO, I gather that we'll need to work that out at the BOFs. But I hope that it fits within one of them.

----- Original Message -----
From: "Salman Abdul Baset" <[email-masked]>
To: "Enrico Marocco" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 15, 2008 9:16:17 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

-s

---

From: Lars Eggert <[email-masked]>
Date: Tue, 15 Jul 2008 16:44:58 +0300

>> with FTTH access and a DSL ones, when no additional information is

Agree with Enrico.

> example, with this information, a P2PSIP application running on one  
> of several machines behind the cable/DSL modem can more accurately  
> determine the presence or absence of self-interference. In the  
> absence of self-interference and after network usage has left the  
> P2PSIP application convinced that it has enough capacity, it can  
> advertise itself as a relay in the overlay.

Sure, we can dream up all kinds of information that would be useful to  
an app or protocol: accurate and timely topology graph information,  
accurate and timely congestion information, accurate and timely  
latency information, etc. App wants to know this stuff? Talk to the  
oracle - done!

This misses a bunch of key issues, though:

   * Is it even possible for the oracle to gather all this
     information? It's difficult for an app, sure - but why
     do we think it will be easier for an oracle?

   * How accurate would this information be, how timely would
     it be and what is the cost to gather and keep it up-to date?

   * How much interdepence does this create between layers that
     were so far more loosely coupled? Are we giving up evolvability?

   * How much "better" (for some definition of better) will this
     information let the app become? Is it worth the architectural
     complexity?

To make this concrete, lets go back to the self-interference example:  
How would an access router figure out that a bunch of flows are  
interfering? On what timescales would this detection mechanism  
operate, and how sensitive would it be? Will the router need to assume  
that all flows adhere to some specific congestion control mechanism?  
How much will performance be improved?

Without at least a credible attempt to answer these sorts of  
questions, I don't think we have a basis to begin thinking about  
standardization.

(And I agree that the more baked proposals in the ALTO space do have  
answers here.)

Lars

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 15 Jul 2008 11:34:55 -0400 (EDT)

On Tue, 15 Jul 2008, Lars Eggert wrote:

>> Information about self-interference can guide peer selection. For example, 
>> with this information, a P2PSIP application running on one of several 
>> machines behind the cable/DSL modem can more accurately determine the 
>> presence or absence of self-interference. In the absence of 
>> self-interference and after network usage has left the P2PSIP application 
>> convinced that it has enough capacity, it can advertise itself as a relay 
>> in the overlay.
>
> Sure, we can dream up all kinds of information that would be useful to an app 
> or protocol: accurate and timely topology graph information, accurate and 
> timely congestion information, accurate and timely latency information, etc. 
> App wants to know this stuff? Talk to the oracle - done!

I certainly did not mean the extrapolation mentioned above :). I was 
refering to Enrico's point whether determining self-interference can guide 
peer selection. The concept of self-interference needs to be properly 
defined, though. Oracles are not a panacea for every problem and certainly 
not a solution for determining timely and accurate congestion or latency 
information. In addition, where to place oracles or their equivalent is an 
open question.

The self-interference example and any ALTO solution must address the 
questions you raised. I will attempt to address your questions for the
self-interference example later.

-s

> To make this concrete, lets go back to the self-interference example: How 
> would an access router figure out that a bunch of flows are interfering? On 
> what timescales would this detection mechanism operate, and how sensitive 
> would it be? Will the router need to assume that all flows adhere to some 
> specific congestion control mechanism? How much will performance be improved?
>
>
> Without at least a credible attempt to answer these sorts of questions, I 
> don't think we have a basis to begin thinking about standardization.
>
> (And I agree that the more baked proposals in the ALTO space do have answers 
> here.)
>
> Lars

---

From: Laird Popkin <[email-masked]>
Date: Tue, 15 Jul 2008 14:17:40 -0400 (EDT)

To address Lars' point below, I think that the "oracle" is probably not the best place to ask about link level congestion, as that's a real-time stat, so the the best place to answer that question is probably the ISP's router nearest the edge (or DSLAM, etc>) but it might be the right place to ask for the location of the device to ask. :-)

----- Original Message -----
From: "Salman Abdul Baset" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 15, 2008 11:34:55 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

-s

---

From: Laird Popkin <[email-masked]>
Date: Tue, 15 Jul 2008 14:22:21 -0400 (EDT)

Yep. :-) This could apply not only to people in a home sharing a broadband connection, but also to homes using a shared broadband (e.g. DOCSIS).

----- Original Message -----
From: "Salman Abdul Baset" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: "ext Laird Popkin" <[email-masked]>, [email-masked]
Sent: Tuesday, July 15, 2008 7:58:33 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

-s

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 15 Jul 2008 12:23:40 -0700

The router's in the path.  It would seem the most obvious way to ask  
it is to just send a packet, and the router would fiddle with  
something in the header.

Explicit congestion control is hard to deploy and is a pie-in-the-sky  
of transport-level solutions.  Often, it can be approximated end-to- 
end more easily.  End-to-end is just so much easier.  It is also  
desirable to move forward in the explicit direction.  Problem is at  
this point we don't know what the right thing to communicate is -- it  
remains a research rather than an engineering question.  It's also not  
something that is easy to experiment with -- imagine the total cost of  
the RED and ECN experiments.  And they're some of the most lightweight  
forms of explicit congestion control.

-- Stas

On Jul 15, 2008, at 11:17 AM, Laird Popkin wrote:

> To address Lars' point below, I think that the "oracle" is probably  
> not the best place to ask about link level congestion, as that's a  
> real-time stat, so the the best place to answer that question is  
> probably the ISP's router nearest the edge (or DSLAM, etc>) but it  
> might be the right place to ask for the location of the device to  
> ask. :-)
>
>>> example,
>>> application
>> questions, I

-- 
Stanislav Shalunov
http://shlang.com

---

From: Laird Popkin <[email-masked]>
Date: Tue, 15 Jul 2008 15:25:49 -0400 (EDT)

That seems like a reasonable approach.

----- Original Message -----
From: "Stanislav Shalunov" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, July 15, 2008 3:23:40 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO BoF - generalize the problem

-- Stas

-- 
Stanislav Shalunov
http://shlang.com

---

From: stefano previdi <[email-masked]>
Date: Wed, 16 Jul 2008 16:01:22 +0200

> From: Stanislav Shalunov <[email-masked]>
> 

I wonder how operators would like to "open" their backbone routers to such
external requests... while I see the benefit of an ALTO server to interfaces
them.

s.