Re: draft-santitoro-rap-policy-errorcodes-01.txt

[Andrew Smith <ah_smith@pacbell.net>]

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.
> 
>  
> 
> 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:mrg@nortelnetworks.com]
>     *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:wweiss@ellacoya.com]
>     *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:dromasca@avaya.com]
>      > 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:ah_smith@pacbell.net]
>      > > 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
>      > >
>      >
>