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

From: "McCaffrey, Bryan (CA - Toronto)" <[email-masked]>
Date: Mon, 2 Dec 2002 15:45:10 -0500

Could end-to-end call admission control also be used (vs. just link-specific
controls) for "b" below? As far as I know, Cisco's implementation of CAC
uses the concept of a "call" described as a unit of bandwidth, 64Kbps at
present. 

-Bryan

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]] 
Sent: Monday, December 02, 2002 11:17 AM
To: [email-masked]
Cc: ieprep
Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

On Monday, Dec 2, 2002, at 10:30 America/Montreal, [email-masked] 
wrote:
> [MAP] So take this simple case and apply an emergency. (I'd like to
> see the performance last week right after the bombing in Kenya!)
>
> If 10 or 20 or whatever number of those "several thousands" of end
> users tried to make a VoIP call via that single 384K link, what would 
> have happened? It is my understanding that, at some point, the 
> overload would have caused either:
>
> 1. all calls to be of unacceptable quality
> 2. new call attempts would have been rejected

	The IP-layer doesn't have the concept of a "call", so (B) can't
happen 
at
the IP-layer.  Bill's SIP server is not on the access link (as I 
understand it),
so would not be subject to the emergency -- it would be able to process 
calls
normally without any MLPP.  (Bill please clarify these points.)

	If congestion on the last mile link occurred (which we don't know 
right now),
then it could ONLY be solved using link-specific deployed mechanisms 
(e.g. router
CoS like Sprint/Genuity described would be sufficient).  If congestion 
occurred,
then what would have happened is probably packet loss (after the packet 
buffers
on the access routers filled up).  How much packet loss occurred 
depends on the
depth of those buffers, the offered load, the link capacity, etc.  So 
we don't
know whether congestion occurred (yet, Bill should ask) or exactly what 
happened
if it occurred.

	It is entirely possible that the Nairobi VoIP user was in fact
having 
no
problems using his link during that situation.  As of this second, we 
don't
know (and Bill should ask).

> I and others have asked this question numerous times, but have not
> seen any hint of an answer, just claims that one should 
> "overprovision" to prevent this from happening. Clearly, 
> overprovisioning or adding capacity in real time can not solve the 
> problem in this situation. I'm looking for a concrete solution. I have 
> been lead to believe that there is none at present, thus the existance 
> of IEPREP.

Concrete existing solutions:
	1)	Deploy link-specific QoS.  For DSL see T1/ANSI/ITU-T
standards,
		for Ethernet see 802.1p, for cable modems see DOCSIS
standards.
	2) 	Deploy access router CoS (a la Sprint/Genuity product
offerings).
	     This is already widely available and is outside of IETF's scope

since
	     it is an implementation detail inside of a router.

Please STOP claiming that concrete solutions to the access link 
congestion
issue have not been offered.  It is a bold-faced lie and it is quite 
tiresome
at this point.

And please STOP claiming that IETF lacks mechanisms that DoD could use 
to
deploy MLPP internally.  DiffServ is on the standards track already with AF
and EF.  So that is another bold-faced lie.

It is just not productive when you keep repeating claims that are 
obviously untrue
to anyone reading the list's archives.

Ran
[email-masked]

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

---

From: [email-masked]
Date: Tue, 03 Dec 2002 15:11:55 -0800 (PST)

[RAN]
>the endpoints could react in any of several ways.  An
example
>that seems most obvious to me would be to switch from
G.711 to a more robust
>CODEC that consumes less bandwidth (e.g. some form of
CELP).

[Alan]
I could agree with the switching (see bellow) to lower
bit rate, but would disagree with switching to CELP,
which is bad since CELP is statefull, packets have
memory and due to this interpacket memory dependency
error propagates further, so by losing packet number N
You are losing properties of the packet N+1, and it
takes quite  some time for CELP to recover state,
resulting with degraded quality. See:
http://www.ietf.org/proceedings/02mar/slides/avt-6.pdf
http://www.cs.columbia.edu/~library/TR-repository/reports/reports-2001/cucs-016-01.pdf
moreover, I can provide You with a great deal of other
references. This behavior is not strange, if we bear on
mind that principally CELP codecs were not designed for
usage in packet networks rather for wireless or circuit
switched nets, where they supposed to cope with bit
errors instead of packet/frame loss.
 
[MAP]
>If my application is handling my phone call, first, I
don't know what functionality tells it about packet
loss or latency or jitter at the other end, 
unless we add specific measuring protocols (which I
thing are being worked on). If my application had a way
to know about excess packet loss at the other end
(presumably caused by there being too many other people
trying to talk over the same link), what could it do
about it? It could switch to a lower speed codec,
thereby giving everyone a slighty lower packet loss
ratio (including myself), but I would surely get worse
quality from the lower speed codec. (If it were a
better codec, I would have selected it in the first
place.)

[Alan]
This change in basic (with no impact of impaired net)
perceived quality is almost negligible for average
users for a number of low bitrate codecs..

[MAP]
>Or my application could switch to a higher bandwidth
utilitzation, like adding more forward error correction
to make up for the lost packets or to a higher rate
>codec that is less suseptable to packet loss, thereby
giving everyone a slightly higher packet loss ratio
(including myself), but I probably get better quality
(at >least as far as packet loss is concerned).

[Alan]
I would not agree with this solution since it will most
likely cause even greater packet loss if number of
other endpoints are doing the same thing, furthermore
calls that do not increase bit rate have better chances
to have smaller packet loss and delay values (since
number of routers on slow access link use WFQ as a
default and recommended mechanism)

[MAP]
>This plan works if there is an intelligent entity in
the middle that forces all users to switch to a lower
rate codec (and accept lower quality). This is clearly
not t>he answer in the Internet model.

[Alan]
I agree. Therefore  we should utilize what we have
available in terms of codec technology, and other
endpoint specific technologies that will improve
quality such as advanced jitter buffers, packet loss
concealment mechanisms etc. etc. …  and eventually come
up with some guidelines for that part.

Best regards,
Alan Duric