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

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

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.
 
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.
 
regards,
 
-Walter
-----Original Message-----
From: Mark Gibson [mailto:[email-masked]]
Sent: Monday, February 05, 2001 10:09 AM
To: 'Weiss, Walter'; 'Dan Romascanu'; Andrew Smith; Ralph Santitoro
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Sadly, when I put a proposal to the SIP wg that integrated route choice with
SIP signalling, it got rejected out of hand in *favour* of the multi-round
trip SIP then do RSVP approach that was championed by SIP-DCS. Everything
helps when attempting to reduce the post-dial delay to a manageable level,
though I would imagine the SIP signalling part would always consume the bulk
of PDD time. 
 
However, this draft is good in that it permits early rejection of unsuitable
TSpecs - if you don't have the capacity for a new session, why set the
ADPSEC low to reflect this and wait for the called party to reject. Better
is to reject it straight away thus saving the amount of Path state installed
(and then removed) and then let the caller (software) decide how to handle
things.
 
Mark
 
-----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Monday, February 05, 2001 2:21 PM
To: 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH]
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
 
Dan, 
A number of studies have been done that describe telephone user
expectations. Interestingly enough, these expectations differ greatly
depending on the situation (landline vs mobile, local vs international,
etc.) I am aware of a specific target, but I don't recall the source. I
recollection is vague on this but I seem to recall something like 300ms.
Hence my prior concern over back to back H.323/SIP and RSVP negotiation
overhead.
regards, 
-Walter 
> -----Original Message----- 
> From: Dan Romascanu [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Monday, February 05, 2001 12:57 AM 
> To: Andrew Smith; Ralph Santitoro 
> Cc: rap 
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt 
> 
> 
> Hi Andy, 
> 
> If IP Telephony is the application, one measure of "quickly", 
> "fast", etc. 
> would be how much you would allow from a phone user 
> perspective between the 
> moment dialing ended until you hear the phone ringing ("call 
> accepted'') or 
> the network returning you a "busy" signal ("call rejected"). 
> 
> Regards, 
> 
> Dan 
> 
> 
> > -----Original Message----- 
> > From:       Andrew Smith [SMTP:[email-masked]] 
> > Sent:       Sat February 03 2001 9:59 
> > To: Ralph Santitoro 
> > Cc: rap 
> > Subject:    Re: draft-santitoro-rap-policy-errorcodes-01.txt 
> > 
> > Ralph, 
> > 
> > Can you provide some quantitative data here e.g. some units 
> and values to 
> > go 
> > with "immediately", "quickly", "fast" etc. It's hard to 
> make the right 
> > protocol 
> > design tradeoffs with people using such qualitative terminology. 
> > 
> > Thanks, 
> > 
> > Andrew 
> > 
>

---

From: Andrew Smith <[email-masked]>
Date: Mon, 05 Feb 2001 09:55:31 -0800

But, again, you are using phrases like "add significantly" without any numbers 
to back them up: let's have some hard data please. How long do RSVP hops take in 
modern equipment? How long does a COPS-RSVP interaction take? How do these 
numbers compare to the click-click-click of uniselectors (or their solid-state 
equivalents) in the voice world? Are peoples' perceptions here based on real 
production implementations of RSVP or based on prototypes running ISI rsvpd (no 
offence intended, but I believe that that implementation is designed as a proof 
of concept).

Andrew

Weiss, Walter wrote:

> 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.
> 
>  
> 
> 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.
> 
>  
> 
> regards,
> 
>  
> 
> -Walter
> 
>     *From:* Mark Gibson [mailto:[email-masked]]
>     *Sent:* Monday, February 05, 2001 10:09 AM
>     *To:* 'Weiss, Walter'; 'Dan Romascanu'; Andrew Smith; Ralph Santitoro
>     *Cc:* rap
>     *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt
>     
>     Sadly, when I put a proposal to the SIP wg that integrated route 
>     choice with SIP signalling, it got rejected out of hand in 
>     **favour** of the multi-round trip SIP then do RSVP approach that 
>     was championed by SIP-DCS. Everything helps when attempting to 
>     reduce the post-dial delay to a manageable level, though I would 
>     imagine the SIP signalling part would always consume the bulk of PDD 
>     time.
>     
>      
>     
>     However, this draft is good in that it permits early rejection of 
>     unsuitable TSpecs ? if you don?t have the capacity for a new 
>     session, why set the ADPSEC low to reflect this and wait for the 
>     called party to reject. Better is to reject it straight away thus 
>     saving the amount of Path state installed (and then removed) and 
>     then let the caller (software) decide how to handle things.
>     
>      
>     
>     Mark
>     
>      
>     
>     *From:* Weiss, Walter [mailto:[email-masked]]
>     *Sent:* Monday, February 05, 2001 2:21 PM
>     *To:* 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH]
>     *Cc:* rap
>     *Subject:* RE: draft-santitoro-rap-policy-errorcodes-01.txt
>     
>      
>     
>     Dan,
>     
>     expectations. Interestingly enough, these expectations differ 
>     greatly depending on the situation (landline vs mobile, local vs 
>     international, etc.) I am aware of a specific target, but I don't 
>     recall the source. I recollection is vague on this but I seem to 
>     recall something like 300ms. Hence my prior concern over back to 
>     back H.323/SIP and RSVP negotiation overhead.
>     
>     regards,
>     
>     -Walter
>     
>      > From: Dan Romascanu [mailto:[email-masked]]