Subject: RE: [NSIS] Message Looping in GIMPS

From: "Hancock, Robert" <[email-masked]>
Date: Sat, 20 Mar 2004 09:24:40 -0000

ok - we should distinguish between

*) easy to add later - doesn't change the rest of the protocol 
processing rules

*) hard to add later - it's mainly useful when a high percentage of
the nodes implement it but a lot have been deployed without it

i think the route recording function matches both these. i agree 
with the debugging aspect being important, and important from the 
start (i don't believe the qos-nslp needs that have been mentioned
actually need route recording themselves, i write something about that
later). 

i'd be very happy to see someone define a 'diagnostics NSLP' 
which could even become a MUST/SHOULD to implement along 
with GIMPS (apart from anything else, it would give us a 
non-trivial NSLP to play with). there are probably other 
diagnostic functions that are also needed (some sort of e2e
echo, for example).

r.

-----Original Message-----
From: Henning Schulzrinne
To: Hancock, Robert
Cc: Nsis (E-mail)
Sent: 20/03/2004 02:39
Subject: Re: [NSIS] Message Looping in GIMPS

> 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: Xiaoming Fu <[email-masked]>
Date: Sat, 20 Mar 2004 10:43:24 +0100

Hi,

> diagnostic functions that are also needed (some sort of e2e
Earlier we had an attempt with a simple "traceroute", described in 
http://user.informatik.uni-goettingen.de/~fu/paper/draft-fu-ccamp-traceroute-00.txt 

http://user.informatik.uni-goettingen.de/~fu/paper/IETF-fu-ccamp-traceroute.pdf 
(presentation slides at IETF#57 - CCAMP WG)

We are currently prototyping it. If interested we would be glad to work 
with the team and extend it towards diagnostics NSLP.

Regards,
Xiaoming