|
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
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
> >
>
|