Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

From: [email-masked]
Date: Thu, 20 Nov 2003 09:29:34 EST

In a message dated 11/19/2003 7:57:47 PM Eastern Standard Time, 
[email-masked] writes:

> One possible solution for the lower priority calls would be a terminal 
> behaviour such that if a certain percentage 
> (or number) of packets are lost in a certain amount of time, 
> the terminal issues a congestion notice to the other party and either the 
> call is suspended 
> for a short period of time or terminated.  
> 

Yes, I believe this has been suggested. The obvious problem is trying to 
define an algorithm that would allow a terminal to distinguish between packet loss 
from congestion that isn't going to go away, and packet loss that is going to 
go away rather quickly anyway (as in my example), and packet loss due to 
something other than congestion. I tend to think that this is not possible.

Suspending a call for a short period sounds worse than the random packet loss.

Mike Pierce

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 20 Nov 2003 14:39:22 -0500

Responses below.

It seems to me that if bandwidth is scarce, silence suppression is a major
benefit. Typical users only speak for one third of the time.  But the CAC
simply reserves enough bandwidth in each direction for continuous speech -
A factor of 3 in actual utilization.  Does this seem a reasonable approach
to anyone?   One key question is how the the MLPP crowd intends to do voice.
Do they intend to use silence suppression?
 How serious are they about MLPP?   Since I am now unemployed, I don't have
much access to current thinking.

In addition, for large networks with low bandwidth trunks, it may be
difficult to build a CAC that can handle the network.  Has anyone
done a CAC to handle the DOD forces in the Middle East?   I would assume we
don't have much fiber there.  Can anyone supply the relevant facts or are
they classified?

Steve
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Thursday, November 20, 2003 9:30 AM
  To: [email-masked]; [email-masked]; [email-masked]
  Cc: [email-masked]
  Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

    the terminal issues a congestion notice to the other party and either
the call is suspended

  Yes, I believe this has been suggested. The obvious problem is trying to
define an algorithm that would allow a terminal to distinguish between
packet loss from congestion that isn't going to go away, and packet loss
that is going to go away rather quickly anyway (as in my example), and
packet loss due to something other than congestion. I tend to think that
this is not possible.

  SS:
  It seems to me that counting pkt losses per time period is easy.  The
question is whether it is useful.  If calls were suspended for perhaps 10
seconds
  with a message indicating that this was being done, that might be more
acceptable than disconnection.  Currently in the CS environment, preempted
calls
  are simply given a tone and terminated.  I would think that this would be
preferable. If the congestion lasted more than the 10 seconds,
  then the call would be terminated.  It would be nice if a practical  CAC
were implemented but I am skeptical about that.

  Suspending a call for a short period sounds worse than the random packet
loss.

  SS:  I'd like to try this on some people and see which they prefer.  But
it seems to me that disconnecting 5% of the routine calls is preferable to
having 50% of the calls continue unintelligibly.  That appears to me to be a
major waste of bandwidth not to mention the time and frustration of the
actual people involved.

  Mike Pierce

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Nov 2003 13:59:38 -0600

At 02:39 PM 11/20/2003 -0500, Steve Silverman wrote:
>simply reserves enough bandwidth in each direction for continuous speech 
>-  A factor of 3 in actual utilization.  Does this seem a reasonable approach
>to anyone?

Are you suggesting the choice is no CAC or CAC that might waste 2/3rds of 
the BW for that session?

>One key question is how the the MLPP crowd intends to do voice. Do they 
>intend to use silence suppression?

I've not read yet that they do

>  How serious are they about MLPP?

very

>Since I am now unemployed, I don't have much access to current thinking.
>
>difficult to build a CAC that can handle the network.

Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750, 2753, 2996, 3175 
and 3181. The first and last of this list are especially relevant to your 
environments

>Has anyone
>done a CAC to handle the DOD forces in the Middle East?   I would assume 
>we don't have much fiber there.

Connectivity and bandwidth awareness are the issue here, not whether there 
is fiber or not

>Can anyone supply the relevant facts or are they classified?

I believe testing and analysis should be done prior to proposing solutions 
to incomplete requirements

>Steve

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

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

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 20 Nov 2003 12:19:25 -0800

Steve, there are a couple dimensions to the issue and we're right in 
the middle of them in some DoD programs now.

Your observation that a two-party (or even multiparty) conversation 
has a lot of dead time in it is correct.

 From that we have a couple derivatives:
	- a single end system (policeman, first responder on scene) 
will have both voice and non-voice IP applications (a position report 
from the radionav box that he carries, for example).
	- if you lash up a 2.4k pipe which was designed for 
circuit-switch voice, and pump IP datagrams over it, the end node is 
likely to be a single end system, not a router fronting for a bunch 
of stuff on the backside LAN.  This amplifies all of the shortcomings 
of a radio link -- low interactivity and such -- because you've lost 
the benefits of IP multiplexing.  Note that we've been here many 
times before in the Internet -- router-to-router, once it becomes 
reality, results in us consolidating the available bandwith into a 
smaller number of larger-sized pipes.
	- the first responder metaphor of a policeman with a handset 
in his fist is probably not the one we want to envision.  Rather, 
that policemen is sorta wearing a LAN with his VOIP end system, his 
position reporting box, his camera, etc all attached.

At 2:39 PM -0500 11/20/03, Steve Silverman wrote:
>Responses below.
>
>It seems to me that if bandwidth is scarce, silence suppression is a 
>major benefit. Typical users only speak for one third of the time. 
>But the CAC
>simply reserves enough bandwidth in each direction for continuous 
>speech -  A factor of 3 in actual utilization.  Does this seem a 
>reasonable approach
>to anyone?   One key question is how the the MLPP crowd intends to 
>do voice. Do they intend to use silence suppression? 
>  How serious are they about MLPP?   Since I am now unemployed, I 
>don't have much access to current thinking.
>
>done a CAC to handle the DOD forces in the Middle East?   I would 
>assume we don't have much fiber there.  Can anyone supply the 
>relevant facts or are they classified? 
>
>Steve
>
>>One possible solution for the lower priority calls would be a 
>>terminal behaviour such that if a certain percentage
>>the terminal issues a congestion notice to the other party and 
>>either the call is suspended
>Yes, I believe this has been suggested. The obvious problem is 
>trying to define an algorithm that would allow a terminal to 
>distinguish between packet loss from congestion that isn't going to 
>go away, and packet loss that is going to go away rather quickly 
>anyway (as in my example), and packet loss due to something other 
>than congestion. I tend to think that this is not possible.  
>
>
>SS: 
>It seems to me that counting pkt losses per time period is easy. 
>The question is whether it is useful.  If calls were suspended for 
>perhaps 10 seconds
>with a message indicating that this was being done, that might be 
>more acceptable than disconnection.  Currently in the CS 
>environment, preempted calls
>are simply given a tone and terminated.  I would think that this 
>would be preferable. If the congestion lasted more than the 10 
>seconds,
>then the call would be terminated.  It would be nice if a practical 
>CAC were implemented but I am skeptical about that.
>
>
>SS:  I'd like to try this on some people and see which they prefer. 
>But it seems to me that disconnecting 5% of the routine calls is 
>preferable to having 50% of the calls continue unintelligibly.  That 
>appears to me to be a major waste of bandwidth not to mention the 
>time and frustration of the  actual people involved. 
>
>
>
>
>Mike Pierce

-- 
b

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 20 Nov 2003 16:55:26 -0500

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> James M. Polk
> Sent: Thursday, November 20, 2003 3:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>

No.  I am saying that if silence suppression is used (and I think it
should be used) the
 deterministic busy signal calculation of the Circuit Switched world
is impossible in a Packet Switched
world.  Consequently, to maximize the utility of limited bandwidth,
some prioritization is required
and mechanisms to work within this environment need to be addressed.

> Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750,

The only reason I mention fiber is that in general, fiber provides an
abundance
of bandwidth but here I am focused on the case where bandwidth is a
scarce resource.

> to incomplete requirements

I fully agree.
We had been   analyzing and testing before our funds ran out.
Is anyone looking at these issues and running the
appropriate testing.  I hope that my current impression that
these issues are being ignored is incorrect.

Steve

---

From: Fred Baker <[email-masked]>
Date: Thu, 20 Nov 2003 08:26:59 -0800

>packet loss due to something other than congestion. I tend to think that 

actually, the obvious problem is that if we are dropping traffic from a 
precedence class, we are dropping roughly equal amounts from all calls 
within that class. If it is bad enough that some calls would give up, one 
must presume that all relevant sessions will at minimum ask the question. 
Why does one believe that they will not all, or some significant subset, 
drop? if this is done at a time when a number of sessions are being 
established, this becomes a rolling pattern - if we have enough calls for 
110% of the bandwidth, and are therefore dropping 10% of traffic in the 
precedence class, one would expect calls to drop and re-establish randomly 
in a rolling pattern.

The policy and predictability of the system is pretty suspect, I think.