Re: When route is changing....?

[Polly Huang <huang@catarina.usc.edu>]

On Tue, 12 Oct 1999, Lloyd Wood wrote:

> 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...

understood. but session routing may exaggerate the degree of disordering.

> 
> 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...

We might meant the same thing.  What I was trying to say is that
packets may come in an order that's different from what we would expect
with a more detailed routing implementation, which usually takes some time
to converge on new routes. During the transition, data packet might be
lost somewhere (and perhaps retransmitted later) as oppose to that
session routing allows new routes to be computed right at the moment
and succeeding packets will have no problem (maybe just a little) taking
the new routes to the receiving ends. 

> 
> 
> > 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?

Ah.. I see here might be where the confusion is.  Session routing is
somewhat like a centralized unicast routing. It is not SessionSim.

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

Agree. You caught me here. I wasn't thinking when I wrote that statement.
In fact, I might have been too optimistic about session routing...  Any
design/protocol whose behavior varies with ordering of
packets should be careful about using session routing.

Cheers,
-Polly 

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