Re: [p2pi] Information in an ALTO protocol

Exactly.

The instantaneous transfer rate, based on congestion status, etc., is a highly variable condition that is in scope for TANA.

The provisioned transfer rate, for use in making application level decisions, is (IMO) in scope for ALTO.

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

----- Original Message -----
From: "Stanislav Shalunov" <shalunov@shlang.com>
To: "Laird Popkin" <laird@pando.com>, "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
Cc: p2pi@ietf.org
Sent: Monday, September 15, 2008 4:52:58 PM (GMT-0500) America/New_York
Subject: RE: [p2pi] Information in an ALTO protocol

Figuring out how fast to send based on real-time network management is congestion control, and thus a transport question.  I believe it's in scope for TANA.

-- Stas

-----Original Message-----
From: "Laird Popkin" <laird@pando.com>
To: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
Cc: p2pi@ietf.org
Sent: 9/15/08 9:52 AM
Subject: Re: [p2pi] Information in an ALTO protocol

The main problem is not only that the measurement accuracy is low, but  
that fairly often even an accurate measurement of the instantaneous  
measurement is not representative of typical throughput that the app  
should be configured for.

This is a complex area, so there's lots of interesting research. For  
example:

- http://www.rfc-editor.org/rfc/rfc5136.txt defines terminology
- http://mice.cs.columbia.edu/getTechreport.php?techreportID=500&format=pdf& 
  proposes a method (and has lots of links to other tools and research).

So while there are plenty of clever methods for trying to figure out  
end user link capacity, they're all complex methods of estimation. If  
I can get the ISP to tell me, that's simpler and more reliable. Of  
course, I can't count on the ISP to always do so, so the various  
methods of estimating link capacity remain useful. :-)

- LP

On Sep 15, 2008, at 11:06 AM, Nicholas Weaver wrote:

>
> On Sep 15, 2008, at 7:54 AM, Laird Popkin wrote:
>
>> The cost of bandwidth testing isn't terrible, but the accuracy of  
>> measurements taken on 1K transfers is very low - you're really  
>> measuring latency and buffering, not sustained data transfer rate.  
>> Of course, there might be some relationship between them, but (at  
>> least in our measurements) it took much larger data transfers to  
>> get even remotely stable results. In addition, measuring actual  
>> throughput at a point in time can be affected by other traffic on  
>> the PC (e.g. PC's do many things when they're starting up), other  
>> nearby PC's (e.g. someone else in your neighborhood is busy right  
>> now), transient interference on the internet, etc. So while it's  
>> not unreasonable to do such testing, and we certainly do so, an ISP  
>> provided provisioned capacity would be much more accurate (when  
>> it's available).
>
> The point of the 1K back-to-back packets is NOT that you are testing  
> the transfer time for the 1K packets, but that interarrival time of  
> the packets can be used as an uncongested-link bandwidth estimate,  
> as long as the queue at the point of congestion uses FIFO delivery  
> of packets.
>
> Since the question you are asking the user is "whats the  
> UNCONGESTED" behavior as a starting point (to set an initial  
> threshold/ceiling somewhere below this point), the behavior of back- 
> to-back packets should get you in the right ballpark without having  
> to ask the user.
>
>

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi