Subject: RE: [NSIS] comments on draft in-path and out of path (draft-sche len-nsis-opopsig-00.txt)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 9 Jul 2002 17:30:13 +0200

Hi Olov

Please my remarks/comments in line and after the word [georgios]!

Best Regards,
Georgios

-----Original Message-----
From: Olov Schelén [mailto:[email-masked]]
Sent: Friday, July 05, 2002 2:32 PM
To: Georgios Karagiannis (ELN)
Cc: [email-masked]'; [email-masked]
Subject: Re: [NSIS] comments on draft in-path and out of path
(draft-schelen-nsis-opopsig-00.txt)

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

"Georgios Karagiannis (ELN)" wrote:

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

[Olov] 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.

[georgios] What I tried to say is that what is described in RFC2992 should also be considered as
traditional L3 routing. MPLS is not L3 traditional routing.

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

[olov] 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.

[georgios] Yes, but this then will also held for the out of path approach! Therefore, this 
issue is not only an on path issue, but also an out of path issue!
Please be fair with your comparison!

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

[olov] 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.

[georgios] In this situation the distributed policy servers are on path. But the way of how the 
common understanding is provided is out of scope of NSIS.

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

[olov] 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.

[georgios] yes e2e is difficult in both models, but ensuring out of path QoS support 
is more difficult than the in path QoS support. What I tried to emphasize here is 
that we need to be fair in the comparison of these two approaches.

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

[olov] I refer to my response to your previous comment.

[georgios] I also refer to my previous reply to your previous remark.

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

[olov] 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.

[georgios] In my remark I wanted to emphasize that a centralized entity located out of path
needs to efficiently configure, efficiently manage resources, and efficiently communicate with
the routers that are on path and are not using the NSIS protocol. When these procedures 
have to be performed on demand (and online) are more complicated 
then the procedures that have to be used for an on-path approach.

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

[olov] 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.

[georgios] Yes, but you present it as a benefit of the out of path approach (not as a 
benefit for the on-path approach). Please be fair with your comparison!

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

[olov] 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.

[georgios] Yes, in the situation that the implementation is distributed and out of path 
there will not be a single point of failure. However, I think that there will be much less 
points of failures than in an on-path approach. Thus, the failure detection and error recovery 
procedures are much more important in the out of path approach, compared to the on-path 
approach.

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

[olov] 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.

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

[olov] 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.

[georgios] Well, there are a lot of studies that show that centralized entities in networks are 
performance bottlenecks.

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

[olov] 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.

[georgios] Only if the number of the out of path entities is limited!

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

[olov] For these two, see previous responds.

[georgios] Please see also my previous responds.

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

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

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

---

From: [email-masked]
Date: Wed, 10 Jul 2002 19:26:40 +0200

Hello Georgios,

again, thank you for your feedback.

> Please be fair with your comparison!

Georgios, I agree that every ISP that will carry IP flows signalled by
NSIS (so almost all ISPs) must build/configure its network in such a way
the signalling will always "follow" the data path, be it on or off-path. 
This *is* an issue with an on-path protocol in a network making "non
traditional routing". And we don't think we can force every ISP to have
traditional routing.
Of course if a on-path signal is send in the bad direction, an off-path
NF downstream won't fix it, we never said that.
And I think we are fair when we talk about solutions in 4.2.3. We wrote
a router can implement the required signalling carrier function that
will redirect the signals in the right direction. This can also be done
in an off-path NF. 

> common understanding is provided is out of scope of NSIS.

The way is out of scope. But it can have impacts if there is a way, a
standardized way, or not. Anyway, the fact that the signaling is off the
data path can facilitate the fact that the policy servers are on the
signaling path. Distributed does not necessarily means inside a router
for me.

> that we need to be fair in the comparison of these two approaches.

Georgios, I think that 3.2.3 is honestly written. As you correctly point
out, routers may not implement Intserv for RSVP, and this has also been
written in 3.2.3.

> [georgios] I also refer to my previous reply to your previous remark.

Georgios, I don't follow you on the assumption. First, 4.2.1 discuss one
benefit of off-path which is independance of signalling plane and
forwarding plane. This is more about economical and migration advantage
than about bandwidth consumption.
To come back to the overprovisionning issue you raise here, I tend to
think that off path can be better, if not the same. But it is true this
has not been explicitely written. 
Here  if we can have one off-path NF that checks for the same QoS
request two links/pipes (they are counterparts of trunks in aggregated
RSVP, for instance), there will be one state for these two pipes/links.
On the other hand, there will be 2 verifications in two RSVP aggregators
and two states, one in each RVP aggregator.

> then the procedures that have to be used for an on-path approach.

What are these procedures? We already identified synchronization with
routing tables, and admission control in the issue chapter. 

> benefit for the on-path approach). Please be fair with your comparison!

That is true we placed in in the benefits of off-path. Why? Because
off-path solution require no change in the legacy routers. Maybe this
point could be merged in 4.2.1, but 4.2.1 was more about a general and
long term characteristic af the off-path solution, while 4.2.3 focus on
a particular problem of today.

> [georgios] Well, there are a lot of studies that show that centralized entities in networks are

It sure that a trade off must be done between centralization and
distribution. But here I don't really see the difference between
off-path and on-path. Maybe off path is more flexible.

> [georgios] Only if the number of the out of path entities is limited!

Sure. But do you think off-path NF number is illimited?

Best regards
-- 
Alban Couturier
---------------------------------------------------------------------
Alcatel Research and Innovation
Ets de Marcoussis R&I/ULC
Route de Nozay                      mailto:[email-masked]
F-91461 Marcoussis CEDEX                       tel: +33 1 69 63 11 97
---------------------------------------------------------------------