|
Yoram,
I
would agree that a simple response for Do-Not-Send and less than best-effort is
valid. However, I don't believe that either of these do much for IPT or the
goals of the errorcodes draft. In other words, what are the call setup delay
requirements for a Do-Not-Send and less then best-effort
response?
regards,
-Walter
OK.
I agree that there are problems that arise when the full path is not examined
beofre returning a DSCP with a PathErr. I think that, at least in certain
applications, the value of the mechanisms in the draft justifies work to
investigate and address the problems. For example - while selecting the
'right' DSCP for a service might be difficult, returning a less than
best-effort DSCP coul;d be easier. Certainly, retunring a DO_NOT_SEND can be
doen without understanding the impact on downstream
subnetworks.
Y
Yoram,
In
essence, I am both agreeing and disagreeing. I am agreeing that "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." I am disagreeing with the premise that a PathErr with
an alternate DSCP achieves the aforementioned objective, particularly when
considering the interdomain issues I raised previously.
regards,
-Walter
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?
|