Re: [p2pi] Refining the ALTO problem statement

[Laird Popkin <[e-mail]>]

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: [phone]

----- Original Message -----
From: "Lars Eggert" <[e-mail]>
To: "ext Stanislav Shalunov" <[e-mail]>
Cc: "Laird Popkin" <[e-mail]>, [e-mail]
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: [phone]
>>
>> ----- Original Message -----
>> From: "Stanislav Shalunov" <[e-mail]>
>> To: "John Leslie" <[e-mail]>
>> Cc: [e-mail]
>> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi


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