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?