2009/10/11 wang hui <[email protected]>: > 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.
Numerous studies have reported the existence of triangle inequality violations (TIV) in the Internet delay space（for about10%-30%）. It has been proved to be a stable phenomenon in the Internet, and it is due to the flaw of IP routing protocol. Since it is impossible to modify the existing IP protocol, using QoS relay will be a complement to IP routing. > >>> >>> | (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
