Subject: Re: [p2pi] Refining the ALTO problem statement

From: Laird Popkin <[email-masked]>
Date: Fri, 27 Jun 2008 08:41:51 -0400 (EDT)

I think that we're all in violent agreement in the distinction between long-term network status (e.g. topology, capacity, distance, cost) and transient status (e.g. congestion).

Specifically, I think that we agress that "oracles" should focus on long-term network status and not transient status (e.g. congestion).

But where I'm not sure that we agree is in the definition of ALTO's scope. There are many kinds of transport-level information that are valuable to expose to the application layer that aren't being addressed by other efforts (AFAIK). So while Re-ECN communicates stream-level congestion status, I believe that there is also value in exposing "last mile" link status (and capacity, quotas, etc.) to applications to assist them in making better decisions (e.g. avoiding 'last mile' link congestion, avoiding running consumers over their quotas, etc.). So while arguably last-mile link congestion is a "transport layer" issue, if it's not addressed elsewhere, perhaps ALTO should address it?

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

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "ext Stanislav Shalunov" <[email-masked]>
Cc: "Laird Popkin" <[email-masked]>, [email-masked]
Sent: Friday, June 27, 2008 3:14:15 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Refining the ALTO problem statement

On 2008-6-27, at 0:21, ext Stanislav Shalunov wrote:
> Knowledge about congestion is a transport topic.  Improvements in  
> transport are possible, and, I would argue, necessary.  Congestion  
> information is useful on entirely different timescales and is a very  
> different problem.  An uncongested path may well be congested  
> seconds later.  An inexpensive path is likely to remain such  
> tomorrow and even a week later.
>
> Congestion pricing and variations of ECN to achieve it is a very  
> interesting topic, but not an ALTO topic.

It will surprise nobody that I fully agree with Stas.

Lars

>
>
> -- 
> Stanislav Shalunov
> http://shlang.com
>
> On Jun 26, 2008, at 10:54 AM, Laird Popkin wrote:
>
>> I agree with Stanislav's main point (ALTO should focus on providing  
>> new information). We've had extensive email chains listing such  
>> opportunities, so no need to repeat them here.
>>
>> That being said, there's some value in knowing about congestion  
>> more precisely than we do now. In particular, it would be good to  
>> know when:
>>
>> 1) The user's internet connection is saturated (and in which  
>> direction) so that the application as a whole can reduce bandwidth  
>> to de-saturate the link. Many p2p apps do this now, but the  
>> techniques for attempting to indirectly detect 'edge' link  
>> saturation are inconsistent in their effectiveness. If the edge  
>> router could tell app's the precise situation, that would help  
>> app's avoid saturating links while maximizing performance.
>>
>> 2) A specific TCP stream to a specific peer is saturated, in which  
>> case we should slow down that stream and pull more data from  
>> elsewhere. Re-ECN looks like it'll address the latter scenario.  
>> What's the relationship (if any) between Re-ECN and ALTO?
>>
>> - Laird Popkin, CTO, Pando Networks
>> mobile: 646/465-0570
>>
>> ----- Original Message -----
>> From: "Stanislav Shalunov" <[email-masked]>
>> To: "John Leslie" <[email-masked]>
>> Cc: [email-masked]
>> Sent: Monday, June 23, 2008 7:58:39 PM (GMT-0500) America/New_York
>> Subject: Re: [p2pi] Refining the ALTO problem statement
>>
>> On Mon, Jun 23, 2008 at 9:45 AM, John Leslie <[email-masked]> wrote:
>>> P2P applications have good reason to want to know (instantaneous)
>>> congestion, and what the likelihood is that the congestion will get
>>> better or worse soon.
>>
>> This is the function of transport.  P2P apps, by doing e2e
>> measurements, already have pretty decent information about state of
>> congestion, and use it just the way you'd expect.
>>
>> What P2P apps don't have, and what ALTO should provide, is new
>> information -- not whether a path is congested, but whether a path is
>> preferred by the ISP.  Some simple notion of cost or preferred ASes  
>> or
>> IP prefixes or whatnot.
>>
>> This is information that the routing layer has and that the overlay
>> routing in P2P has no access to.
>>
>> --
>> Stanislav Shalunov
>> http://shlang.com/
>> _______________________________________________
>> p2pi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> 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: Fri, 27 Jun 2008 16:00:41 +0300

Hi,

On 2008-6-27, at 15:41, ext Laird Popkin wrote:
> I think that we're all in violent agreement in the distinction  
> between long-term network status (e.g. topology, capacity, distance,  
> cost) and transient status (e.g. congestion).

I think we are, although I'd question whether capacity is long-term  
status. If you mean capacity as in "the potential capacity of the  
bottleneck link along a path", then probably yes, but if you mean  
"currently available bottleneck capacity", then likely not.

> I believe that there is also value in exposing "last mile" link  
> status (and capacity, quotas, etc.) to applications to assist them  
> in making better decisions (e.g. avoiding 'last mile' link  
> congestion, avoiding running consumers over their quotas, etc.). So  
> while arguably last-mile link congestion is a "transport layer"  
> issue, if it's not addressed elsewhere, perhaps ALTO should address  
> it?

ALTO, as a BOF targeted at the RAI and APP areas, is not the right  
place to discuss these issues. Transport area topics do need to be  
discussed in transport area meetings.

The original proposal for the transport-area TANA BOF, which came out  
before there was public information about ALTO, had a similar work  
item, because it seemed likely after the P2PI workshop that folks  
would want to discuss mechanisms related to transient network status.  
When the ALTO proposal was submitted, the ADs decided it would make  
more sense to split the work items identified at the P2PI workshop  
into things for TANA and things for ALTO, but it was at least my  
understanding that this split came with an agreement that obviously  
transport-related topics would be out of scope for ALTO.

Lars