On Tue, 2010-10-26 at 23:53 +0100, Stephen D. Strowes wrote: > achievable state with respect to the state requirements.
s/state/stretch/ -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
