Re: [RRG] ALT's strong aggregation often leads to *very* long paths

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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 rrg-request@psg.com 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