Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 5 Feb 2001 11:47:10 -0500

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
-----Original Message-----
From: Yoram Bernet [mailto:[email-masked]]
Sent: Monday, February 05, 2001 11:30 AM
To: Weiss, Walter; 'Mark Gibson'
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

-----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Monday, February 05, 2001 7:44 AM
To: 'Mark Gibson'
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

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?