Hi Sebastian, On Friday, July 12, 2013, Sebastian Kiesel wrote:
> Hi Richard, > > On Fri, Jul 12, 2013 at 11:41:30AM -0400, Y. Richard Yang wrote: > > Hi Sebastian, > > > > On Fri, Jul 12, 2013 at 10:14 AM, Sebastian Kiesel > > <[email protected]<javascript:;> > >wrote: > > > > > Qiushi, > > > Richard, > > > > > > On Fri, Jul 12, 2013 at 09:44:56AM -0400, Y. Richard Yang wrote: > > > > > Section 1.2.2 > > > > > > > > > > It's not obvious that the measurement overhead can be reduced by > > > > > conducting only fine-tuning or fault-tolerant measurement. It's > better > > > to > > > > > list the parts of the overhead which can be removed. > > > > > > > > To avoid the details and the complexity that follows, we can remove > the > > > > word fine-tuning and say only that the application can use ALTO info > > > about > > > > latency and bandwidth, if provided, and hence no need to measure the > > > > latency or bandwidth itself. How does this sound? > > > > > > I think the word fine-tuning shouldn't be removed completely. But maybe > > > we need some fine-tuning of that paragraph :-) > > > > > > The motivation for this paragraph was to say that, in the P2P scenario, > > > if you really want to know throughput values you will have to measure > > > them yourself (in the overlay). ALTO can give some predictions who > could > > > be good other peers and who not, but there are may reasons why ALTO may > > > not be accurate (see sec. 8.2.3. of draft-ietf-alto-deployments-06). > > > > > > One of the main benefits of ALTO is that if I join a new swarm, ALTO > may > > > give me some promising ("better-than-random") peers to start > > > communicationg with, but then I should do some fine-tuning of my peer > > > lists based on own measurements. So the saving of overhead is probably > > > not saving traffic for probe messages (many measurements are done on > the > > > regular application traffic anyway) but it is faster convergence to a > > > good state. > > > > > > > > Good discussion. Please see below for the revised text: > > > > An application that uses an ALTO Service can benefit from > > better knowledge of the network to avoid network > > bottlenecks. For example, an overlay application can use > > information provided by the ALTO Service to avoid selecting > > peers connected via high-delay links (e.g., some > > intercontinental links). > > > > > Instead of using third-party > > databases such as geo-location databases, the application can > > use ALTO as a standard to obtain related information. > > I don't like this sentence, as it somehow mingles who provides > information ("third-party" -- we have an own paragraph on who could > possibly become an ALTO provider) and through which standard > interface/protocol (ALTO vs. (proprietary) databases). > > Maybe just omit it. > > Using ALTO as a unifying interface is a benefit of a standard. But it is indeed better that we delete the sentence. > > > Using > > ALTO to start each node with promising > > ("better-than-expected") peers, an adaptive peer-to-peer > > overlay may achieve faster, better convergence. > > Maybe replace "start" with "initialize". > > OK. > What is "better-than-expected"? Please repeat the wording > "better-than-random peer selection" from the ALTO problem statement > document. Sure. It was a typo. Thanks! Richard > > > Thanks > Sebastian > > p.s.: thanks to Qiushi for the review! >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
