Robin, <snip> > > ... 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
Certainly there's an issue if the initial retransmission timeout is systematically less than the actual initial RTT. I believe the Windows default is 3 seconds, for example. If the RTT turns out to be 4 seconds, we have a problem. But as long as we steer clear of that problem, I still don't see why adding the mapping delay to the DNS delay (given that both answers will be cached in the case of repeated sessions to the same server) is going to be a significant problem for the users. > 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. Not if the timers are right. TCP will still be quietly waiting for its SYN/ACK. Media streams will start up just a second or two more slowly. I really don't see why users will be any more disturbed than they are today by existing session set-up delays. > > 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. Certainly, no delay is better than delay. > > 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. I assume you mean "push-everything" schemes, and given that some are arguing for 10^10 map entries, I have great difficulty agreeing that any push-everything scheme is deployable. At the 10^8 level it seems conceivable. Brian -- 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
