Mark,
I would actually expect RSVP to consume more time
than SIP. There are two factors to consider. First RSVP is a hop by hop
protocol. While in practice most hops would have RSVP disabled, I would
still expect 2 hops best case (at the LAN/WAN transition points) and 2
hops per DS domain (once at ingress and once at egress) worst case.
Further, in the new model for RSVP, the protocol is used more as a policy
proxy than to configure switches. As such, when a RSVP message is received,
it is likely to be redirected to a PDP via COPS before propogating the
message. The redirection and processing are also likely to add significantly
to the delay.
[Yoram
Bernet] Just a minute - policies are cached. In the steady
state, RSVP messages are not redirected to PDPs *before propagating the
message*!
My main reason for suggesting this alternative is
because there is no implicit binding between a DSCP and a service level. Let
me be a little clearer. There is no well defined DSCP for voice, let alone a
less optimal DSCP. Further, DSCPs are configured and have unique QoS
semantics on a per domain basis. It is highly likely that IPT traffic will
pass through at least three domains. As such any of them can not only demote
a service, but potentially promote a service as well. Irrespective of the
course taken, there are two things to be avoided. One is the exclusive
reliance on DSCP mappings. If the Path is rejected on the ingress, but a
specific alternate DSCP is offered, there is an inherent and flawed
assumption that the DSCP will mapped properly across DS domains resulting in
non-deterministic behaviour. Second, we should avoid inconsistencies in the
expectations of the sender and the receiver. With a reservation in place
(irrespective of the service level), both the sender and
receiver understand the bounds the behaviour. Further, with a
non-optimal reservation, the opportunity exists to only use the less optimal
DSCP in those portions of the network where contention prevents the use of
the optimal DSCP. In other words, the optimal DSCP in some portions of the
network can improve overall service characteristics.
[Yoram
Bernet] Are you saying that DSCPs cannot reliably invoke
services? What is the "Serv" part in DiffServ then? With the correct
admission control and the correct provisioning and traffic conditioning,
DSCPs can invoke specific services. The network understands how it is
provisioned and just what services DSCPs can offer through it. That's why
the network must inform the user, which DSCP should be used for a particular
service. I agree with you that interdomain issues are important and that a
DSCP in one domain may mean something different than a DSCP in another
domain, but - that is why it is all the more important to tie domains
together through some higher layer abstraction - such as signaling for a
certain type of service, across all intervening domains. Are you rejecting
RFC2996-2998? Or do you agree witht he direction in
those?