Hi, Some additional comments inline. Hui Wang Beijing University of Posts and Telecommunications,Mobile lIfe and New mEdia(MINE) Lab
2009/10/11 Tao Ma <[email protected]> > Hi, > Some comments inline. > Tao Ma > Beijing University of Posts and Telecommunications,Mobile lIfe and New > mEdia(MINE) Lab > > >> >> >> Hi Yu Meng, >> >> On Tue, Aug 25, 2009 at 10:24:08AM +0800, [email protected] wrote: >> > Hi, >> > We have submitted a draft on relay usage for ALTO. This document would >> > describe the background of Qos relay and design the mechanism of >> combining >> > ALTO service with relay. >> > >> > The draft can be found at >> > http://www.ietf.org/internet-drafts/draft-meng-alto-relay-00.txt. >> Comments >> > welcome. >> >> Your draft mentions two use cases: the first is the "Connectivity relay" >> to connect users with limited Internet access (NAT). I fully agree with >> that use case and I think that ALTO should be able to assist in >> selecting an "optimal" (in the sense of ALTO) connectivity relay. >> >> >> However, I am very concerned about the second use case, on which your >> document focuses: the "QoS relay". With the goal of lower latencies you >> are proposing an Application Layer-routing/forwarding mechanism that >> diverts traffic from the path along which normal IP routing would send >> the packets: >> >> | Under the following two conditions, overlay >> | routing paths can be faster than the direct IP routing paths >> | (1) An AS in a direct routing path is congested or failed. >> >> Can you please explain which timescales we are talking about? >> >> Do you want an ALTO-based solution to reroute around suddenly appearing >> failures/congestion faster than the IP routing protocols can do? >> >> Or is it all about routing around chronically congested links, >> which are known to the operators to be congested but which they >> do not want to upgrade for some reason? >> > RE: I think relay is a method of overlay routing which has the function of > bypassing some congested IP path. IP routing can recover from failure too. > But overlay routing cares more about the application metric. Their > understanding of failure or congestion might be different. For example, for > VOIP application which has stringent delay requirements, IP rerouting > mechanism can’t detect some paths that are actually congested in the view of > the application requirements. In ALTO-based solution, overlay rerouting > might be complementary for IP rerouting especially for some QoS > requirements. > To be added, there actually exists interaction between overlay routing and IP routing. In my opinion, the interaction of them, especially for the rerouting of failure recovery, needs further research and discussion. > >> >> | (2) Multi-homed customer ASes can further improve overlay routing. >> >> If we look at Figure 1 of your draft, can you please explain how the >> owner of the AS B can publish what kind of transit traffic he is willing >> to relay through a "QoS relay" in his multi-homed stub AS (if he wanted >> to relay all kinds of IP traffic, AS B could just become a transit AS on >> BGP level)? Should this policy-aware detection of candidate relays be >> part of ALTO? >> > RE: In ALTO-based solution, relay is application relay. As long as there > are “QoS relay” in AS B, an overlay path which traverses AS B can be > established, which needs no modification on BGP level. In other words, this > solution can be seen as policy unaware, for it doesn’t care about IP routing > policy. > To my understanding, ALTO-based solution doesn't depend on IP routing policy. But it may refer to some BGP information.As is shown in 3.2:"ALTO server might use BGP routing information to calculate the preference of relay candidates that P2P application provides. The rating method can be seen in [draft-racz-bgp-based-alto-service]". > >> >> Thanks, >> Sebastian >> >> -- >> Sebastian Kiesel mailto:[email protected] >> Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 >> NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, >> Germany >> -- >> NEC Europe Limited Registered in England 2832014 >> Registered Office NEC House, 1 Victoria Road, London W3 6BL >> >> >> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
