Subject: [NSIS] comments on draft in-path and out of path (draft-schelen-nsis-op opsig-00.txt)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 3 Jul 2002 16:59:48 +0200

Dear Olov and Alban

I have read your draft and I have some comments mainly on Sections 3 and 4 (see below).

Best Regards,
Georgios

Comments on Section 3.2.1:
------------------------------------

Comment_1 on Section 3.2.1:
-----------------
You mention  that:
"The on-path signaling relies on the fundamental assumption that packets are all routed the 
same way, based on the IP destination address. This will be called in this draft the
 "traditional IP routing."
[georgios] Right but, you should not exclude other types of routing. In my opinion an 
on path solution should consider
the possible cases described in {RFC2992] regarding:
 "Analysis of an Equal-Cost Multi-Path Algorithm".
In general, if the signalling protocol uses the same routing protocol as the data 
path then the signaling
 messages and their associated data path packets will have to follow the same path.

Comment_2 on Section 3.2.1: 
-------------
I do not understand this comment:
"In these cases, a signaling unaware cloud is not anymore a signaling carrier, 
as nothing assures it 
will forward the signal at the same place it will forward the dataflow."

[georgios] If the signalling protocol uses the same routing protocol as the data path then the 
signaling messages and their associated data path packets will have to follow the same path. 
This will have to be ensured even if the signaling protocol is not used in a certain domain.
A network provider may for example need to configure the network such that signalling path 
messages follow the same path as the data path messages. However, this is  a reasonable 
requirement, since a network provider should be able to configure many other parameters 
in his network.
-------------------------------------------------------------------------------------------------

Comment on Section 3.2.2
---------------------------
In this section you are talking about centralized policy servers.
What about distributed policy servers? Distributed on the edge nodes of a domain!
-------------------------------------------------------------------------------------------------

Comment on Section 3.2.3
-------------------
You mentioned:
"One problem of RSVP and intserv is that every router in the network must implement 
intserv and RSVP in order to link the sink and the source with a chain of QoS capable 
routers that all allocate 
resources for the flow."

[georgios] not all routers in a communication path have to implement Intserv. 
Actually, you mighty have domains that are overprovisioned and do not implement Intserv.
What I try to say is that this issue applies to both types of architectures,
i.e., on path and out of path. Therefore, it is not fair to presented here as an on 
path issue!
-------------------------------------------------------------------------------------------------

Comment on Section 4.2.1
-----------------------------
You mention that there are benefits of using independent signaling plane and forwarding plane.
This is only a benefit only when only you will assume that the forwarding plane is 
overprovisioned or, etc.,
You can get the same situation with an on path signaling when you will assume that 
a network  consists of a concatenation of domains and the only routers that are using 
the NSIS protocol are only few edge nodes. This is after assuming that all the other routers 
are overprovisioned.
Thus I do not see this issue as a benefit of the out of path architecture!
-------------------------------------------------------------------------------------------------

Comment on Section 4.2.2
---------------
You mentioned that VoIP or multimedia network applications rely on servers 
such as soft switches, gatekeepers, etc.,,.
You also mention that on-path signaling solutions require complex deployments that can be 
avoided thanks to the placement's flexibility associated to the off-path model.
In my opinion the solutions that are needed for a centralized entity located out of path
to efficiently configure, efficiently manage resources, and efficiently communicate with 
the routers that are on path and are not using the NSIS protocol are much more complicated than 
the solutions that you will need to use when the servers are located on path.

Comment in Section 4.2.3
------------------------------
This benefit is associated with an on path disadvantage given in Section 3.2.1. 
The comment that I gave there applies also here!
In general, if the signalling protocol uses the same routing protocol as the data path 
then the signaling
 messages and their associated data path packets will have to follow the same path.

Comment in Section 4.3
----------------------------

I would like to add some more issues with the out of path signaling:
The out of path signaling scenario, compared to the in-path
signaling, introduces the need of a centralized architecture
(which can in turn be distributed).  Having an architecture
with centralized decision-making capabilities means that
certain kinds of issues must be handled:

 * There may be a single point of failure

   Failure detection and error recovery are tremendously
   important.

 * Checking for availability of resources within a domain may be
   based on either static or dynamic configuration data.
   If this is done dynamically, the RTT of the signalling
   protocol itself could be increased. This is an addition to the text
   that you propose in Section 4.3.2.

 * The centralized resource management entity might become
   congested faster due to the higher number of signaling
   requests compared to a distributed resource management
   architecture.

 * Sophisticated mechanisms for discovery of the centralized
   entities are needed. This is an addition to your Section 4.3.1.

 * Routing of signaling messages might affect the routing of
   data path. This is similar to the issue explained in 
   Section 4.3.1.

 * Anytime a handover or a route change takes place, the
   routing of the data path may change.  Mechanisms are needed
   to relate the path that signaling messages and data path
   packets follow. This is similar to the issue explained in 
   Section 4.3.1.

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

---

From: Olov Schelén <[email-masked]>
Date: Fri, 05 Jul 2002 14:32:07 +0200

Georgious,
thank you for your comments. I have included my response below.
/Olov

> Comments on Section 3.2.1:

In RFC2992, nothing is said on that load-balancing is REQUIRED to be based on source-destination
pairs of addresses only.  The same holds for any traffic engineering methods. How this is done by
real implementations I am not sure about, but would appreciate feedback on this. My understanding is
that divergence of signalling-path and data-path can happen, at least at some points in the network.
With MPLS there may be an approach for sending real-time traffic (e.g. VoIP) on separate LSPs and
also to transfer the traffic to next domain on different interfaces.

> Comment_2 on Section 3.2.1:

The problem here is that there may be domains along the path (perhaps over-provisioned and not
signalling-aware) that do not follow this recomendation. In the backbone there is probably multiple
peering-points, so once the signalling has diverted it may enter following domains at different
ingresses.

Yes they can be distributed physically, but they are logically centralized in the sense that they
have a common understanding the commitments and resource availability in the domain.

> Comment on Section 3.2.3

Yes, there may be over-provisioned and QoS un-aware doamins in both cases, so ensuring e2e QoS is
difficult in both models.  We do here however emphasise the need for having the signalling support
in routers at all. Although only in edge-routers (as we explain) there are plenty of edge routers
that need to handle this signalling.  This is to compare with off-path (application-level)
signalling that does not require particular support in routers at all.

I refer to my response to your previous comment.

> Comment on Section 4.2.2

 Standards-wise the off-path model only needs a high-level protocol to be set (e.g. containers over
TCP and possibly also over some well known applicaton level protocol). In addition, it would be nice
to use an efficient standard for setting traffic conditioners at edges (e.g., COPS-PR plus
standardised PIBs, SNMPCONF plus standardised MIBs, etc). Standards-wise this is simpler, relatively
speaking. Note that conditioners would only be operated at microflow-level at accesses, while the
rest would be on larger aggregates (constrained on destination prefixes, etc) . Implementation-wise
I see only your opinion, so I respond only by ensuring that there are solutions that are just
running fine.

> Comment in Section 4.2.3

Our intent here is to state exactly what you say, i.e., that the problem of keeping track of
non-traditional routing applies also in the off-path case.

> Comment in Section 4.3

Failure detection are tremendously important in both models. In the off-path model there is no
single point of failure when the implementation is distributed (and nodes can operate independently
). I see that the same problem applies for on-path, so I agree that we should add this as an
importand issue in general.

>    that you propose in Section 4.3.2.

Well, thats true if you  prefer to do it that way. However, instant traffic measures are often not a
good basis for predicting the future. Rather you would rely on periodic feedback and perhaps
heuristics. Anyway this information will be collected as a background process that does not affect
the RTT of the signalling itself.

>    requests compared to a distributed resource management

It is very hard to make definite statements about performance in both models. Evaluation by real
operators is probably the best way to go. However, servers are dealing with this kind of
computational tasks quite well, while routers are good at packet forwarding (not known for handling
slow-path tasks very efficiently). Also hierarchical aggregation keeps down the overhead.

>    entities are needed. This is an addition to your Section 4.3.1.

QoS controlers can also be configured with peering relations (much like BGP-routers are configured
with peering-relations today).  For end-hosts (in case it would be desirable for hosts to be
initiators), configuration could be through dhcp-like mechanism.

> _

For these two, see previous responds.

> ______________________________________________
> nsis mailing list
> [email-masked]

--
Olov Schelén, CTO             Operax AB
Tel    +46 920 7  5516        Aurorum 8
Mobile +46 705 79 5516        SE 977 75 Luleå
[email-masked]       www.operax.com