Randy Turner <rtur...@amalfisystems.com> wrote: > > Of the methods expressed below... > > On Jun 3, 2009, at 11:20 AM, John Leslie wrote: > >> Three quite different ways come to mind: >> >> 1) Express the maximum you will (ever) see in the foreseeable future; >> >> 2) Express the maximum you will see for (all of) an extended period; >> >> 3) Express the maximum right now with a "time-to-live". > > #1 is basically unusable.
It seems suboptimal to me, too, but "unusable" overstates the case. If you hit it, you know you won't get any more bandwidth. > #2 and #3 seem the same...where the "extended time" is the value of > the TTL But with #3 you _know_ the TTL, while #2 leaves you guessing. The advantage of #2 over #1 (when TTL isn't explicitly available) is that the ISP can request a bandwidth limit for the P2P application to obey (instead of needing to "enforce" it). > It seems like the suggestion is that knowing the link speed of the > broadband pipe provides 2 advantages: > > 1. The P2P app may want to "back off" it's use of the pipe to allow > fair share to the bandwidth for other apps > > 2. The P2P app may be able to tune it's performance, to make maximum > use of available bandwidth, to improve P2P user experience. Also: 3. The P2P app can converge faster to the actual available bandwidth. > The problem is, in order to really achieve this you need some type of > realtime algorithm that determines congestion on the link, I thought this was already needed, though not in scope for ALTO. > and I haven't heard of an idea expressed so far that allows this. LEDBAT seems to be progressing slower than ALTO... Nonetheless, I'm sure folks there have ideas on how to find the bottleneck bandwidth. > The options I've heard so far seem to suggest a way to estimate or > guess what bandwidth might be available at some point. "Guess" is, by definition, suboptimal. > However, there is very negative consequences for invalid assumptions > on the part of a P2P app. Meaning, if there is fuzziness in the method > used to estimate available bandwidth, the implications on other apps > (especially voice traffic) is intolerable. LEDBAT is specifically chartered to avoid excessive latency. > The popular way to properly prioritize traffic from a home network > outbound is for a residential gateway to manage outbound traffic, > since it has knowledge of all the types of traffic trying to use the > link. That sounds out-of-scope... > If we were to design a protocol that "asks" the gateway about current > status, and the gateway reports that the P2P app can "go for it" with > respect to available bandwidth, it's possible that a voice call from a > SIP endpoint somewhere on the home network may startup just after the > P2P app receives the response. Agreed. But the plan, as I understand it, is for that to be LEDBAT's problem; and LEDBAT is merely obliged to back off when latency increases. My concern, BTW, is far more for learning the mininmum-latency number than for learning maximum-bandwidth. And what I want to do with that number is pass it to LEDBAT. Thus, I want ALTO to be _able_ to report such numbers, whether or not they're useful for choosing the order in which peers should be tried. It strikes me as silly to interpret the ALTO charter so narrowly as to forbid passing maximum bandwidth and minimum latency. -- John Leslie <j...@jlc.net> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
