Subject: Re: [NSIS] Message Looping in GIMPS

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Mar 2004 21:39:04 -0500

> what is currently unstated is how the IP TTL is handled in 'forwarded'
> discovery messages. if it is decremented just as if the packet
> were being forwarded at the IP layer, this will also sort out
> loops as you say.

Since these are regular IP packets, I think it would be a seriously 
broken router that did not decrement the IP TTL for these. The path and 
thus the times-around-the-loop may obviously be different even if the 
two types of packets share parts of the path (diverge and merge).

> it was partly the question of how GIMPS would know how to distinguish
> a loop from a spiral which made me cautious here. i agree that SIP-like
> spiralling seems less likely (but maybe that's just because we haven't
> thought of all the signalling applications yet...)

Spiraling occurs, in general, if the destination address can be changed. 
In SIP, that is the request-URI. In GIMPS, this seems a stretch, but if 
you define a loop as visiting the same place twice, it's at least 
theoretically possible:

(1) A sends packet to B, via the border router R(B)
(2) B changes destination address to C, which
(3) causes the packet to visit the border router again

Thus, the packet visits the same *node* twice, but it's not really a loop.

As far as I can tell, such 'hairpinning' can only occur if the 
destination address can be modified. The solution is simple: record both 
the place visited and the address. A loop requires a duplication of both.

That said, I'm at a loss to conjure up an example where such destination 
address changes have any value. (In SIP, they do, since name translation 
is a core protocol function.) Trying hard, maybe a visit from a CH to a 
HA to the FA would cause such hairpinning.

> 
> why would one want to record every NTLP hop? this sounds to me more
> like a signalling application ("clever traceroute") in its own right.

Debugging. We can indeed define this as an application, but to be 
useful, every NTLP node would always have to support it.

In general, I think it is very useful to be able to tell at the edges 
where a packet or message has been. It makes it much easier to see why 
things happen, particularly for places that you can't really 'touch' easily.

Again based on SIP experience, both trace and source routing have proven 
to be extremely valuable. Indeed, the only complaint has been that we 
should have included more of it earlier. I think it would be a mistake 
not to have this capability. It's hard to add later, since its value is 
mainly that everybody implements it.

> 
> this is really a question of what people want (and don't want).
> my reasoning is:
> - everyone would like to keep the NTLP simple (i.e. not put in extra
>   functions)
> - route recording could get complicated to specify and implement

I don't think so. It's very simple - add an address record.

> - route recording seems to have minimal or no interactions with 
>   other NTLP functions (so it would be easy to add later)

No - see above.

> 
> I think a possible approach would be to wait for someone to write
> a proposal for a route recording object and a set of processing rules.
> then we could see how it fit into the current GIMPS design, and also
> how it matched the requirements of different signalling applications.
> in the meantime, not thinking about it doesn't seem to be too risky
> a path to take.

I disagree for the reasons stated above. I think the general experience 
with Internet protocols is that having debug functions from the get-go 
makes implementations more robust and more deployable. Kludging things 
later (as in traceroute, since the original IP mechanism is broken) 
tends to yield suboptimal solutions. (Details about why traceroute has 
problems available on request.)

> r.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 18 Mar 2004 10:05:28 -0000

hi,

> > However, even in the current design, discovery messages are
> > not handled exactly like IP datagrams, because of the policy
> > routing/load balancing problem. If a network implements pf/lb in
> > all its nodes but only some of them are GIMPS aware, discovery
> > messages will be forwarded according to their IP header in the
> > GIMPS unaware nodes but according the flow identifier in the
> > GIMPS aware nodes; therefore, loops are possible. (I think this
> > could probably be counted a pathological condition but it can't
> > be ruled out. In particular, such loops, if they did occur, 
> > probably would not be transient.)
> 
> I don't see how this is different. IP TTL will have the same 
> effect in 
> either case. Given that the flow label is part of the header, I'm 
> confused by the distinction.

the point is that even if your network never loops an 'ordinary'
IP packet, GIMPS packets might loop because they go through a 
different forwarding process from ordinary packets. (e.g. if there
was a routing policy in place in the network about DCCP traffic
being routed a special way, a discovery message relating to a DCCP
flow would be routed like DCCP traffic in a GIMPS aware node, but
like non-DCCP traffic in a GIMPS-unaware node).

> 
> > 
> > In addition, it is still possible that people may want to build
> > networks where C-mode associations are used to trunk signalling
> > messages through GIMPS-only nodes, or there may be other message
> > routing mechanisms added later (e.g. for the path-decoupled case).
> > Once we loosen the connection with IP routing, loop prevention at
> > the GIMPS level becomes a requirement. 
> 
> That is indeed the more likely concern, in addition to efficiency.
> 
> > 
> > So, loop prevention within GIMPS for looping at level (2) is needed.
> > 
> > How to do loop prevention within GIMPS?
> > ---------------------------------------
> 
> > *) it's fast. loop detection will be being done mainly on
> > datagram messages discovering the next NSLP-aware hop, and we know
> > this is a sensitive area for router performance (people would like
> > to do this "get this message past a node which doesn't care about
> > it" in the fast path if possible). So, a check&decrement of a 
> > counter (in the fixed header) is preferable to scanning a route
> > record for an identity and inserting a new field.
> > 
> > *) we expect looping to be rare (it shouldn't come about through
> > GIMPS misconfiguration, initially only pathological IP pf/lb 
> > situations) so detecting it early and efficiently (which a VIA
> > mechanism would do) is less important than making the cost of the
> > processing low.
> > 
> > *) it doesn't lead to message expansion. discovery mode messages
> > are size limited, and adding route records may make them hard to
> > propagate. or, people might want to start record trimming and so
> > on.
> > 
> > *) it's simple. we don't have to get into worries about topology
> > hiding, what namespaces to use for node identities.
> > 
> > So, I would propose to keep the GHC as a loop detection mechanism
> > within the GIMPS layer. (Obviously, the rules about how to process
> > it need to be specified more precisely.) This can then also be used
> > as *one* weapon to handle message looping at the signalling application
> > layer (since NSLPs can read and set the GHC in their messages).
> 
> Note that SIP simply chose to do both, since they have complementary 
> properties (speed of inspection vs. early discovery and better 
> diagnostics). I don't see why we couldn't *allow* (not 
> mandate) that if 
> route-recording is used, that entities can inspect this and use it to 
> discover loops.

i agree - if GIMPS had a route recording capability, there is no
reason not to allow it to be used for loop detection. 

> 
> (As a side note: In SIP, we had to deal with 'spirals', where 
> messages 
> would visit the same node twice, after modification. I don't 
> think this 
> is likely to occur here.)

> 
> > 
> > Should GIMPS provide route recording as a service?
> > --------------------------------------------------
> > 
> > Despite all this, it is still possible (likely?) that there is 
> > a use for route recording for various purposes for use by
> > signalling applications. That may be for loop detection or
> > something else. Loops may be caused by negotiation loops within
> > a single instance of a NSLP (between peers or over a longer
> > distance), or by feedback between microflow and aggregate 
> signalling,
> > or any other sort of reason, and the GHC may not be suitable or
> > powerful enough to handle this. We could make a recording mechanism
> > almost directly out of the comparable functionality in SIP or
> > Diameter.
> > 
> > However, I think this functionality comes into the same class as
> > some other items of 'generally useful signalling protocol' function,
> > like state refresh management or MLPP: it may be useful for several
> > signalling applications, but doesn't have a significant interaction
> > with the other functions within GIMPS itself. Exactly how to make
> > such re-usable components is an interesting question, but our
> > assumption within NSIS (up to now) is that it is a question for the
> > signalling application layer, not for the NTLP layer.
> 
> I respectfully disagree. Since we'd want to be able to record 
> every NTLP 
> hop, not just every NSLP hop, it makes sense to offer this as an 
> optional service within NTLP.

r.