Hi, For your first concern, using ALTO to guide the path selection really has the danger of interaction with IP layer routing. This question is a key issue of this solution. Till now, in my opinion, the difference of time scale(faster than IP like RON) or concern(application Qos vs. connectivity) between overlay and IP layer might be the possible motivation of this solution. For the second concern, about Triangle Inequality Violation(TIV), I have two papers,http://www.cl.cam.ac.uk/~ekl25/p53CameraReady.pdf and http://www.imconf.net/imc-2007/papers/imc145.pdf which focuses on the reason caused by policy. Hope it might be helpful. Can any other add some other references or knowledge about this. Thanks:) Tao Ma Beijing University of Posts and Telecommunication, Mobile lIfe and New mEdia(MINE) Lab
2009/10/12 Sebastian Kiesel <[email protected]> > Hi, > > On Sun, Oct 11, 2009 at 05:10:13PM +0800, miao xiong wrote: > > >>> 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. > > Exactly this is my concern. > > ALTO for initially selecting one of several equivalent resource > providers (i.e., application protocol endpoints that can do stuff far > beyond the functions of an IP router) complements IP routing (obviously > with dependencies). > > In contrast, using relays (which do basically packet forwarding on > another layer in the protocol stack) to divert packets from the "normal" > path really duplicates functions of IP routing. I fear that in the > latter case there is much more danger of undesired layer interaction > than in the first one. > > > > 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. > > Do you have more information (e.g., references to papers/studies) about > the true reasons for TIV? Are they due to > > 1) Non-technical, deliberate decisions of the network operators (e.g., > no business case for upgrading a line)? > > 2) Technical limitations of the IP routing protocols (BGP, OSPF, etc.)? > > 3) Technical limitations of the IP protocol itself (IPv4)? > > or ... > > > Maybe also some people working for an operator can comment on this? > > > > 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
