Subject: Re: [Tsvwg] Revised Congestion Notification Process for Real-Time Traffic ID

From: [email-masked]
Date: Thu, 3 Mar 2005 22:35:11 EST

In a message dated 3/4/2005 8:42:18 AM AUS Eastern Daylight Time, 
[email-masked] writes:

> That makes some interesting assumptions about the application. Do your 
> SIP proxies have knowledge of the routed path between two SIP 
> endpoints, the actual path that data between them will be taking as 
> opposed to the multipath route that it might possibly use, the 
> instantaneous load on that path, and so on? Are they in fact capable of 
> making that decision?
> 

As I understand the proposal, it eliminates the need for any SIP proxy to 
know anything about the specific route being used between two SIP endpoints, as 
opposed to some other proposals for Call Admission Control or congestion 
avoidance which do require some centralized devices to know this, as well as for 
them to know the "instantaneous load on that path".

The routers must already know the routing and could certainly have knowledge 
of the load on its own links, so ECN takes advantage of this by using regular 
packets and regular routing to probe the network for congestion.

If a SIP proxy needs to make any decision, for example, if it is initiating 
the probe for the endpoint, it makes the decision based on the priority of a 
call as indicated in call control signaling. In the simplest case, the decision 
is only whether to allow or not allow the call. There may be a separate 
description of a mechnism to "preempt" an existing call based on the ECN, but it's 
not in this document and should not be.

Is there some other relavent issue I'm missing?

Mike Pierce
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Baker Fred <[email-masked]>
Date: Thu, 3 Mar 2005 21:48:24 -0800

Yes.

OK, so let follow your line of thought.

What is required is that each router in the path that might experience 
congestion is configured to set ECN, and that the telephones negotiate 
its use. Both telephones on the call must agree to use the flags, and 
every router en route must do this DSCP-specific algorithm (Josef 
states that the algorithm is more similar to RFC 3168; I haven't yet 
read this draft, but as the guy providing the network equipment, I want 
the algorithm to be the same, since RFC 3168 is not DSCP-specific). 
Then every telephone that receives the flag must tell his peer that he 
received it (at a time that under VAD rules he is not necessarily 
transmitting), and the sending telephone must now tell whoever is in 
control (presumably his SIP proxy) that he is receiving such. And the 
SIP Proxy must now decide what to do.

In the network I described a couple of emails back, the SIP proxies all 
presumably have disparate policy, and we are saying that because 
Carol's SIP proxy is seeing problems, Alice's SIP Proxy must do 
something. But Carol's SIP proxy and Alice's SIp proxy are under 
different commands and have no means of knowing that each other exist 
or what policies apply.

It's a simplistic solution that presumes something that doesn't exist, 
which is one ubiquitous application that is entirely in control.

On Mar 3, 2005, at 7:35 PM, [email-masked] wrote:

>  As I understand the proposal, it eliminates the need for any SIP 
> proxy to know anything about the specific route being used between two 
> SIP endpoints, as opposed to some other proposals for Call Admission 
> Control or congestion avoidance which do require some centralized 
> devices to know this, as well as for them to know the "instantaneous 
> load on that path".
>
>  The routers must already know the routing and could certainly have 
> knowledge of the load on its own links, so ECN takes advantage of this 
> by using regular packets and regular routing to probe the network for 
> congestion.
>
>  If a SIP proxy needs to make any decision, for example, if it is 
> initiating the probe for the endpoint, it makes the decision based on 
> the priority of a call as indicated in call control signaling. In the 
> simplest case, the decision is only whether to allow or not allow the 
> call. There may be a separate description of a mechnism to "preempt" 
> an existing call based on the ECN, but it's not in this document and 
> should not be.
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Mar 2005 23:46:52 -0700

Fred,

Yes, I agree.   However, legacy telephone and military systems
have an application that is entirely in control.  Do you have a
proposal, or is there a proposal on the table, that will meet
the needs of Military and Telephony applications permitting
decentralized, ad hoc control?  If there is, please direct me
to it.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Baker Fred <[email-masked]>
Date: Fri, 4 Mar 2005 07:59:12 -0800

um, yes,

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-mlpp-that-works 
-00.txt
   "Implementing MLPP for Voice and Video in the Internet Protocol  
Suite", Fred
   Baker, James Polk, 8-Feb-05, <draft-ietf-tsvwg-mlpp-that-works-00.txt>

Two comments:
  - I'm not so sure I agree that the military's network is a single  
happy and
    centrally-controlled network. For one thing, the MLPP policy crosses  
between
    the networks of allied militaries, belonging to different countries.  
Besides
    that, characterizing the US military's networks in those terms is a  
trifle
    brash.
  - but even assuming that military networks are centrally-controlled,  
the example
    I gave was of a civilian service, operating on the open Internet.  
Such exist
    today, and are (if military services are not) the subject of ieprep.