Subject: [Ieprep] RE: Did anyone get any good testing data of VOIP under network congestion?

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 3 Feb 2003 02:26:33 -0600

> For close to 2 years I've been promoting the position we need 
> to deploy some VOIP phones, and get experience using them during 
> periods of severe network stress. We need understand what the 
> problems in the real world are, while working on things which  
> could improve their performance.  
  I accept. Both Ucolumbia wenyu[1] and Stanford Athina[2] research 
would have been more representative, if they had more data points
or access to stuff other than just end systems. With particular
reference to Athena's work, the results are based on probes
sent within a particular set of ISPs. It would have been more 
useful if the above mentioned data sets were available.

> Did anyone collect any data?

  I would be interested in such data sets. 

> 
> On Sun, 2 Feb 2003, Bill Woodcock wrote:
> > It caused very large problems, but was basically contained 
> > within four hours, everywhere that mattered, due in large 
> > communications which now obtain between ISP NOCs.
>
> Unfortunately, I left my INOC-DBA phone at the office, so I 
> wasn't able to try it during the height of the incident. How 
> well did VOIP work during the height of the UDP storm?  
> Would SIP priority have changed how well the VOIP UDP packets 
> got through during periods of severe Internet congestion?
> Or were the real problems somewhere else?

 I have more questions for Bill. Some of the important 
results of athina is that:
  "Although packet voice is in general feasible, many of the 
 measured backbones are not ready to support VoIP today, due to 
 delay variability (in the form of spikes) and loss events. The
 causes of this behavior seem related to network reconfiguration,
 router internal operations and protocol exchanges, and not due
 to congestion[4]."

The data sets are taken from backbone network. Even if taken from 
backbone, what is the actual protocol and configuration 
glitches? If the same measurements were taken in a 
under-provisioned environment, what would be the result? 

Also, sally Floyd has more questions[3]
" > In the IEPREP meeting, the example that occasioned my remark was
   > that of a best-effort, VoIP connection to Nairobi, with good quality,
   > with reports on the viewgraph of typical packet drop rates of 5-40%.
   > It turned out that the VoIP connection was sending 64Kbps, on a
   > 128Kbps link with many users sharing the link.  The voice quality
   > was good.  My question was about the experience of the TCP connections
   > sharing the link at the time."

Currently, MOS is the only quality measure (though we have some theoretical 
models like gilbert etc.) Fred mentioned to me in a discussion that, MOS is 
a subjective measure and we should come up with a better quality measure to 
accurately measure the CODEC rate and frame characteristics. An interesting 
research work will be to build a more predictable quality measure system, to 
replace the current E-model/NetIQ products. We need data (from representative
data points) for experimenting such tools.

The paper also has some good results for Bill& Ran. It is better to concentrate 
on receiver side solutions, loss concealment and playout scheduling than on 
QoS based differentiation. If we use QoS, it will be interesting to map those 
CODEC levels with that of network level quality levels. To do all these, we 
need some real world data.

I am happy to look into those questions, if provided with such a data source.

[1] http://www.cs.columbia.edu/~wenyu/
[2] http://www.sprintlabs.com/people/amarko/publications.html
[3] https://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg01700.html
[4] http://www.sprintlabs.com/people/amarko/PAPERS/IWDC2002/iwdc2002.pdf
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 3 Feb 2003 08:47:23 -0500

>On Monday, Feb 3, 2003, at 07:48 America/Montreal, King, Kimberly S. 
>wrote:
>> Also, last week I was at a conference and presented some information 
>> about
>> ieprep.  One fellow stood up and said that if networks were under 
>> severe
>> network stress then we should be recommending the use of 
>low-bandwidth
>> elastic communications such as IM rather than non-elastic 
>> non-congestion
>> aware applications such as VoIP.  It is also a interesting 
>viewpoint.  
>> (See
>> http://www.saint2004.org/archives/wk6-em/ for the Internet Emergency
>> Workshop presentations including detailed information about IAA.)

Ran said:
>I agree with that fellow, simply because that approach will 
>maximise the
>utility of the network and use of elastic/congestion-avoiding 
>applications
>is visibly better for the overall health of the network at any time.

True but it is also a question of context.  

Case 1:  A traditional disaster (e.g., earthquake, flood) occurs.  This has
traditionally been associated with PSTN congestion into and out of the
affected area.  Suppose we want to use the Internet for emergency
communications.  It is possible that the Internet as a whole does not suffer
from congestion (e.g., September 11) and hence VoIP may be viable especially
if access link issues can be resolved.  Other systems such as IAA are also
quite helpful and can even alleviate some PSTN traffic if folks are content
to see the person in question is safe and therefore don't necessarily pick
up the PSTN telephone.

Case 2: An "Internet disaster" (e.g., a worm or event leading to severe
Internet stress) occurs.  The PSTN may be a fine way to communicate (instead
of VoIP over the Internet) since such an event may be global in scale and
not occurring at a local place where PSTN congestion typically occurs.
Emergency operations that are affected by this type of disaster are those
which use the Internet on a daily basis such as hospitals and ambulances
which use a web interface to exchange information about occupancy and
emergency room status.  These folks should understand their dependency upon
the Internet and maintain backup methods (to avoid single points of
failure).

What I told the man who asked about VoIP is that the scope of Emergency
Communications is vast.  The two cases I've listed are simplifications and
the PSTN and Internet are not totally disjoint systems.  The point is that
it is important for the context be discussed along with the problem and
possible solutions.

Kimberly

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 3 Feb 2003 17:12:08 -0600

> Workshop presentations including detailed information about IAA.)

The *ieprep in IETF* presentation mentions two schemes: GETS and GTPS. 
Any document to read about GTPS? what is the big difference between
GETS and GTPS ( as both seems to be for PSTN)?
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Wed, 5 Feb 2003 06:01:22 -0600

> >maximise the utility of the network and use of elastic/
> >congestion-avoiding applications is visibly better for the 
> >overall health of the network at any time.
> 
> Case 1:  A traditional disaster (e.g., earthquake, flood) 
> occurs.  
> 
> Case 2: An "Internet disaster" (e.g., a worm or event leading 
> to severe Internet stress) occurs.  

> What I told the man who asked about VoIP is that the scope of 
> Emergency Communications is vast.  The two cases I've listed are 
> simplifications and the PSTN and Internet are not totally  
> disjoint systems.

One important point is that Internet traffic is so dynamic that
multiple cases have to be added to the above list. personally, I 
feel sorry for the internet measurement community whose task 
becomes harder with every major worm outbreak, as we become 
increasingly paranoid.

Is your Internet/PSTN option workable model? what is the context
behind the above scenario?

  - off-loading the congestion from PSTN/Internet to the other. 
    I am not sure. But, given the gateway constraints, I don't 
    think off-loading is a viable solution. or

  - PSTN/Internet acting as a back-up to the other.
    If so there are multiple back-up options. An ad-hoc network,
    all type of airline communication etc. what about separate
    spectrum for ieprep :) The charter lists more..PDA, cell 
    phones.

> The point is that it is important for the context be discussed 
> along with the problem and possible solutions.

We have plenty of solutions. We need context to narrow done
the problem space. 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 5 Feb 2003 20:08:18 -0500

>Is your Internet/PSTN option workable model? 
>what is the context behind the above scenario?

I didn't intend these as a "model" but rather to point out the differences
between the ramifications of a traditional disaster
and an Internet security incident. 

>We have plenty of solutions. We need context to narrow done

Yes.  I'll send out a proposed context within a week.

Kimberly