Re: When route is changing....?

[Lloyd Wood <L.Wood@surrey.ac.uk>]

On Mon, 11 Oct 1999, Polly Huang wrote:

> On Tue, 12 Oct 1999, K Sun wrote:
> 
> >     on page 147 in ns Notes and Documentation (July 1, 1999), there are 
> > some words about "Session Routing" (the last two lines of 'sesssion 
> > rouing'), 
> > "
> > ....
> > However, the user should note that the instantaneous recompute of the 
> > routes in the topology can lead to temporary violations of causality 
> > around the instant that the topology changes.
> > ..
> > "
> >    I wonder what "temporary violations of causality" means during "the 
> > instant that the topology changes"? Under my understanding, it should 
> > mean:
> > Because some packets has been delivered in the middle way according to 
> > the previous route, they might be lost (or ..) after route change has 
> > been completed. Anyway, in programs, if we realise some codes to 
> > process such a situation, those packets are still under control.
> > 
> >    I am not sure whether my understanding is right or not. Hope further 
> > explanation for it.
> 
> Sun,
> 
> That means (I think) if new routes happen to be much better than the old
> ones (e.g. bringing up a direct link in between src and dst), packets
> fired at a later time can arrive before earlier packets, which
> might cause events to be triggered in a differenr order (thus called the
> causality problem).

I'm not sure that's it; if routing changes as you describe on e.g. TCP
flows you will get out of order packets and odd effects anyway (I
think Partridge is working on a paper detailing observed traces and
effects on TCP for Transactions on Networking). That is entirely
normal (packet network! feature!), and not a causality variation per
se, since time is still flowing forward. In fact, you'd want to study
it...

What I think it is (and I'm sure Kannan will correct me if I'm wrong)
is that events scheduled at or near the same time as the routing
change may not experience the routing in the network that you would
expect _for that instant in time_ and the neat forwards flow of
simulated time is effectively violated. Effects probably vary
depending on the scheduler...


> SO, if one's design/protocol has strict
> ordering requirement, he or she should aovid session routing  or
> examine carefully whether session routing is appropriate.

Hmmm, since session routing discards queuing delays, there's no chance
of e.g. reordering inside nodes. Bonus feature?

If a protocol design has a strict ordering requirement, it's not much
of a protocol...

cheers,

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>