Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Mon, 2 Dec 2002 16:37:24 EST

In a message dated 12/2/2002 1:42:11 PM Eastern Standard Time, 
[email-masked] writes:

> > 2. new call attempts would have been rejected
> 
> no- the congested link would not cause the SIP proxies to reject calls
> since they have no knowledge of the congestion
> 
> 

[MAP] Although it must be technically possible if the mechanisms were 
defined, that is not what I was suggesting. I meant that whatever entity was 
setting up calls (SIP proxy) would have some knowledge of how many it could 
attempt to setup simultaneously, at least based on the provisioned capacity. 
(The circuit switched world had it easy in this regard.) When the SIP proxy 
reached that limit, it would stop trying to set up more (since they probably 
wouldn't work anyway).

I had approached this work with the (naive?) idea that such CAC functions 
already existed. That is why my draft-pierce-ieprep-pref-treat-examples 
(previously in SIPPING) suggested "higher call acceptance limits" for 
priority calls as one possible method of providing "preferential treatment".

If you're telling me that no such CAC is possible in a SIP proxy, then I 
believe it is impossible to do what we are attempting (VoIP). I don't believe 
that is the case, though.

I have learned, from some other comments, that this lack of being able to 
respond to congestion (by routing changes or blocking calls) is a significant 
problem not only for priority traffic.

Mike Pierce
Artel

---

From: Scott Bradner <[email-masked]>
Date: Mon, 2 Dec 2002 20:11:22 -0500 (EST)

> I meant that whatever entity was

1/ as has been pointed out by others, there is no way to know that
there is any relationship between a particular link and any particular
SIP proxy - many proxies, which have no idea that any other proxies exist, 
can set up calls that wind up going over the same link

2/ > If you're telling me that no such CAC is possible in a SIP proxy

even if it were possible (and I do not know if a vendor has that
sort of feature in their product where the product is not a 
gateway to the pstn (where the number of PSTN links is a hard limit)) 
because of #1 it would not help all that much in many of not most cases 

> problem not only for priority traffic.

the IETF has looked at developing routing protocls that respond to
congestion in the past but there is no such routing protocol
in general use in ISPs (cisco's IGRP did have some features to
try to deal with this but I do not know how many enterprises turned that on

Scott
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 20:25:01 -0500

On Monday, Dec 2, 2002, at 20:11 America/Montreal, Scott Bradner wrote:
> in general use in ISPs

Both IS-IS and OSPF support equal-cost multi-path (ECMP) routing, which
lets a router use a pair of physical links as if it were a single link.
This is widely implemented by many vendors.  Enough customers ask for
this that I think it must have non-trivial deployment.  It is not a
"routing protocol that responds to congestion", but might be relevant.

I agree with Scott's comments.  I'd go farther and say that radical
changes to BGP are unlikely to get past the IDR WG and that ISPs
are unlikely to make wild changes to their IGPs.  (Stable networks
are generally run by risk averse folks).

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 5 Dec 2002 05:01:10 -0800 (PST)

> attempt to setup simultaneously, at least based on the provisioned capacity.

I assume someone's already explained that the provisioned capacity cannot
be determined?  And that the proxy, even if it were able to
instantaneously observe the degree of congestion on path A-B of an
existing call would have no way of using that to determine in advance the
degree of congestion that a call on path C-B might experience?  And that
all that's moot anyhow, since the degree of conjestion this millisecond
isn't likely to be similar to the degree of conjestion next millisecond
anyway, since THIS IS PACKET SWITCHED?

                                -Bill