On Tue, 2010-10-26 at 23:25 +0100, [email protected] wrote: > I am not an expert in compact routing. The good thing: The CR experts > realized themselves how bad it is, hence came up with the term stretch > as to measure its weakness.
Amusing, but wrong. Stretch is a quantifiable measure of how _well_ a routing algorithm performs, and is used in the compact routing work as the primary trade-off against routing state. In particular, the algorithms presented in the literature define provable bounds on achievable state with respect to the state requirements. Cheers, -S. > -----Ursprüngliche Mitteilung----- > Von: Patrick Frejborg <[email protected]> > An: [email protected] > Cc: [email protected] > Verschickt: Di., 26. Okt. 2010, 20:40 > Thema: Re: [rrg] Last call: Design goals > > On Tue, Oct 26, 2010 at 12:43 AM, <[email protected]> wrote: > > > >> I'm not sure where the term was coined, but stretch is a well-known > term > >> in compact routing literature. > > > > Right.Compact routing discriminated hierarchical routing by asserting it > > would induce routes of stretch 17,e.g.. What kind of hierarchical routing > > was that? Obviously a bad concept. > > Those statements hurted my feeling, because I also conceived TARA routing > > (using several hierarchies of zooms) to be some sort of hierarchical > > routing. For TARA shortest path still means shortest path. Period. And of > > course, TARA would also enable detours. > > Hi Heiner, > > I was also a little bit shocked - since I have proposed hIPv4 -when I > noticed that hierarchical routing is a bad choice... > But after studying a bunch of Compact Routing papers I discovered that > when CR researchers are discussing hierarchical routing they are > actually discussing CIDR, i.e. routing tables are kept under control > by aggregating and summarizing prefixes - and a global flat address > space is used. With this concept there will be stretch issues, the > more compact RT the the more likely it is to have a high stretch value > for a session. If I got it all wrong I ask kindly the CR researchers > to correct me, thanks. > > Think this is not the hierarchical routing TARA is proposing, think > TARA falls into Landmark Routing category -there are papers available > on-line and I also found one draft > http://tools.ietf.org/html/draft-ietf-manet-lanmar-05: > > The concept of landmark routing was first introduced in wired area > networks [6]. The original scheme required predefined multi-level > hierarchical addressing. The hierarchical address of each node > reflects its position within the hierarchy and helps to find a route > to it. Each node knows the routes to all the nodes within its > hierarchical partition. Moreover, each node knows the routes to > various landmarks at different hierarchical levels. Packet > forwarding is consistent with the landmark hierarchy and the path > is gradually refined from the top level hierarchy to lower levels > as a packet approaches its destination. > > You might find the paper of Paul Francis Tsuchiya. "The Landmark > hierarchy: a new hierarchy for routing in very large networks" > interesting > > There is also a very nice explanation of the stretch issue in the > paper, see section 2.1 Area Hierarchy > > I also think CR researchers are assuming that the session leverages a > single path between the two endpoints - this is a fair assumption > since the majority of the sessions are either TCP or UDP based. What > if in the future (if it ever happens), most of the sessions are > multipath enabled sessions and the endpoints can have several exit and > entry points between the private network and Internet (multi-homing). > E.g. the initiator have two attachment points to Internet, also the > receiver has two attachment points to Internet. Then the endpoints can > setup four subflows and the transport protocol will most likely found > out which of the subflows have the best throughput, i.e. the lowest > stretch (assuming no congestion occurs) . Thus the question is, to > which degree should the stretch issued be/can be solved by the routing > architecture, how much will/can be solved by a multipath enabled > transport protocol? > > Patrick > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
