Subject: [NSIS] NTLP - separated functionalities

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Nov 2003 12:54:58 +0100

Robert, Henning

it may be worth considering a separation of NTLP 
"route change discovery" from NTLP "service state 
management". Comparing the requirements of both 
funtions, it seems that

- Route change discovery is enabled by 
  connectionless transport and router alert at 
  high detection frequency. The shorter the 
  "route change discovery" interval, the higher 
  service availability.
- Service state management works best with 
  connection oriented (secure, reliable) transport 
  and medium refresh frequency (say every 
  30 seconds at the access, slower at the core).

While above statement in itself may not justify 
a separation of functionalities, a slightly deeper 
analysis of route change discovery may help:

- Both, service provider and user prefer a high 
  service availability. Hence discovery and service 
  restoration should be fast (for now let's say 
  below 5 seconds).
- If route changes are detected by RSVP style 
  refresh packets, their frequency should be in 
  close orders of magnitude at access and core 
  network (say once per second at the access 
  and 100 ms at the core).
- Core Load Balancing in combination with Terminal 
  mobility must not create high signaling load as 
  a result of route change discovery activities 
  while data flows remain "balanced".

Looking at the last three arguments, a fair 
question may be whether separation of route change 
discovery mechanisms from other NTLP functions would 
be a first step only. A second may be to ask, whether 
simple the end-to-end route change discovery approach 
of RSVP can't be replaced by a slightly more complex 
alternative exposing the desired operational 
behaviour in all parts of the network.

Regards, Rüdiger

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Nov 2003 09:08:43 -0500

Thanks for your comments. You are describing a variation of the CASP 
approach, where discovery was a special service.

The current design does not prevent frequent probing, if an application 
so desires and is willing to pay the price in bandwidth and processing. 
The advantage of combining the two is efficiency and faster initial 
setup. I do agree that it may be worthwhile to allow, as an operational 
mode, more frequent, small 'hello' packets between NTLP peers. We'll 
need to work out the details, but I think this can be supported in the 
existing framework. I don't want to make this mandatory since there are 
engineering trade-offs. Sending a probe packet a second is only a 2% 
overhead if you're sending 50 audio packets a second, but it is not so 
great if the packet rate is lower (and/or the data packets are larger). 
We may also revive an approach Ping Pan and I published under the YESSIR 
label, where probing is integrated with the data flow, thus producing 
extremely fast recovery, at the cost of more node processing.

As far as I know, RSVP had a probing interval of 30 seconds, not one 
second or below (although that is obviously tunable).

Route change discovery by probing only matters if routers supporting 
NTLP are far apart, i.e., outside the same IGP. Otherwise, it seems much 
better to just use the routing information to track changes, as that's 
already being delivered for free.