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?