Hi Brian and Noel, I understand you agree with my critique of ALT - that it would delay initial traffic packets, due to it being a global query server system and moreso due to its requirement for strong address aggregation. Both of you seem to regard this as unimportant, or at least as being non-fatal:
BC > From an engineering viewpoint, #3 [Send them a long way round.] BC > seems reasonable (i.e. this minor delay will be added to the BC > other delays for starting an application-level session). NC > In both ALT (I think - perhaps I'm confused about this detail NC > of ALT, if so someone please enlighten me) and LISP+CONS, only NC > the first/first-few data packets (i.e. until the EID->RLOC NC > mapping gets propogated back to the ITR) will be sent NC > (inefficiently) along the server hierarchy; after that, they NC > go direct. Is this slight temporary inefficiency really that NC > important? I think it is really important. Even a half-second delay in session establishment is an enormous burden on all users, since the new kind of mapped address space will, ideally, be used at one or both ends of most Internet communications. Even a half-second delay would make this new kind of address space suck so much that it would be much harder to convince people to use it. Christian Vogt wrote about the slowdown in TCP due to delay or loss of initial packets: http://psg.com/lists/rrg/2008/msg00162.html I wrote in more detail about this: http://psg.com/lists/rrg/2007/msg00462.html My critique of ALT's insistence on strong address aggregation indicates that it will be common for initial packets to be delayed much more than half a second. Beyond a second or so, I think it is fair to say the packet is useless - that the higher layers will have given up and will be try to start another session, perhaps with another destination host where the same trouble might reoccur. The delayed packet may be worse than useless, since it is travelling round the ALT network (and so encumbering the Internet), using resources in ALT routers, eventually emerging at the ETR, using resources there and then being sent to the destination host, which will probably send a response back (more mapping lookups and delays, if the original sender used an EID address too). The response packet will be worse than useless too, since by the time it arrives, the upper layers will be trying to establish another session. I doubt that there could be consensus in the RRG that such delays in initial packet delivery and session establishment would be acceptable unless there was also consensus that all other schemes which do not delay packets (NERD, APT and Ivip) were completely unworkable. Even if ALT could be tweaked to improve its meshiness so as to generally reduce the path length (but meshiness is unlikely to help in every ITR-ETR case), it is still a global query server network - meaning it is slow and unreliable. I think it would probably be more expensive and harder to manage than the push systems it is intended to avoid the need for. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
