Subject: Re: [Ieprep] network congestion, VoIP, NCS contracting approach, etc.

From: [email-masked]
Date: Tue, 12 Nov 2002 13:20:07 EST

In a message dated 11/11/2002 5:40:15 PM Eastern Standard Time, 
[email-masked] writes:

> On Monday, Nov 11, 2002, at 14:00 America/Montreal, [email-masked] 
> wrote:
> > That's why I used the term "preferential treatment" in my drafts, and 
> > only give "prioritisation" as an example of how "preferential 
> > treatment" may be provided. Examples of "prioritisation" (in the sense 
> > of handling one thing in front of something else) would be a device 
> > that queues new call attempts and processes them in a priority order 
> > as resources become available.
> 
> A major issue with even that is that it isn't the functional need of GETS or
> NCS.  The functional need is to get the emergency calls through.  If an ISP
> can do that with only "best effort" and explicitly no support for 
> "preferential
> treatment", the ISP has met the need completely.  If one talks about 
> "preferential
> treatment" then by definition it means the ISP is offering something other 
> than
> pure "best effort" service, so even that gets down into mechanism somewhat
> (though it is fuzzy about which mechanism(s) provide the "preferential 
> treatment").
> 
> So there are still issues with that wording and that conceptual approach.
> 

[MAP] The only "issue" I was raising/commenting on with the above was that we 
should not use the term "prioritization" when we are talking about what 
should be a more generic requirement. Everyone has been correct from the 
beginning that strict "prioritization" of anything (packets, call setup, etc) 
is not a requirement, but rather a possible way to provide "preferenetial 
treatment" for high "priority" calls.

Yes, it is a functional requirement of GETS to provide preferential treatment 
in the case of congestion. The drafts have made this point that it only 
applies if there is congestion. So, if a network can guarantee no congestion, 
that it clearly has no need for any preferential treatment mechanisms.

(I'd like to see a carrier guarantee "no congestion" in a contract with the 
government for GETS!)

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 12 Nov 2002 10:24:10 -0800 (PST)

> (I'd like to see a carrier guarantee "no congestion" in a contract with the

I think we can do that just as soon as one of you channel-switched guys
defines "congestion."  Anybody care to step up to the plate, since that
appears to be prerequisite to the rest of the conversation?

                                -Bill

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

---

From: Dean <[email-masked]>
Date: Tue, 12 Nov 2002 14:46:54 -0500

I believe that congestion can be defined pretty good for VoIP
Two years ago I was working for a VoIP vendor and when we were
implementing the system, this 3 parameters were used to define network
congestion. 

1. packet drop rate 
different vocoders have different treshold, but in general
more then 3% of packetloss, the voice conversation is becomming pretty
not understandable.

2. latency - should be lower then 150ms one way. If it is higher, the
echo cancelation algorythms can not do the work

3. jitter ideally should be 0, but up to 60 msec can be tolerated.

Also, the main problem in implenting VoIP GETS-like services will be
in access not on the backbone.

So far I have not seen much talk about access side. From experience I
can say, when the access was resolved the backbone was comming along
with no problem.

So Bill
you might be right that now VoIP traffic is insignificant, but lets
say there is a disaster and lot of people are trying to reach friends
and realtives from the disaster site, can you image what will happen
on the access loops near the site (inbound and outbound)? And now the
emergency workers need access too. How can we guaranty that?

I believe that this group has to take worst case scenarios and
try to come up with requirements for such cases.

Dean
[email-masked]

===============================================
I like to share my ignorance. I have it enough.

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 12 Nov 2002 12:18:09 -0800 (PST)

On Tue, 12 Nov 2002, Dean wrote:
    > 1. packet drop rate different vocoders have different treshold, but in general

Okay, so 97% packet delivery is a pretty easy target to hit, no problem to
be solved there, that I see.

    > 2. latency - should be lower then 150ms one way. If it is higher,
    > the echo cancelation algorythms can not do the work

Well, us ISPs have been asking for faster light for quite a while now, but
the ITU just hasn't delivered it yet.  I'm not sure that's something we
want to start trying to standardize in the IETF, though...  There'd be too
much argument.  Besides, that's down at layer 1.  :-)

I guess in my experience higher latency has certainly been noticable, but
less so than on the PSTN, since you don't get shoved across satellite
links quite so frequently, it seems like, and the latency isn't quite as
annoying if it's not accompanied by lousy sound quality.  300ms is
certainly tolerable, though obviously increasingly weird.

    > lets say there is a disaster and lot of people are trying to reach
    > friends and realtives from the disaster site, can you image what
    > will happen on the access loops near the site?

Yep.  They may go from single-digit utilization percentages to
double-digit utilization.  Thereby better amortizing their Internet
service fees.  What's being postulated here isn't problematic.  Let's say
that a company has a thousand employees sitting in an office.  Their old
circuit-switched PBX-raised voice services manager says "Ah ha!  If we
have a thousand users, that means we need to be able to support 120
simultaneous conversations, and as everyone knows, a conversation is
64kbps!  Therefore, I will REQUIRE that the Internet service group
MUST give me 7.68mbps capacity for MY EXCLUSIVE HIGH PRIORITY use, and
mark everyone else's packets with a special header which denotes
insignificance, lowliness, and fecklessness."  The Internet service
manager would then receive this report, make a snide joke to her
underlings about people whois heads ring when they're knocked on, assume
that the voice guy was dramatically overestimating his use, and actually
budgets for, say, 1mbps.  Knowing that voice constitutes somewhere between
1% and 10% of her peak traffic mix, and that the sweet spot for pricing is
a DS3, she does what everybody else in his situation does, which is get a
redundant pair of DS3s.

Now, an emergency occurs.  Zillions of really scary clowns surround the
building, trapping all the occupants inside, and making faces at them
through the windows.  The thousand terrified occupants are not, however,
too discombobulated to all simultantously and continuously ring all their
friends elswhere to spread the panic.  1000 x 11kbps = 11mbps = 12%
utilization.  This continues to not be a problem when the clowns get wise
and cut the first DS3.  However, no amount of QoS will fight off the
vicious clowns when their backhoes reach the second DS3, now will it?

    > And now the emergency workers need access too. How can we guaranty
    > that?

Can't.  No requirements document will create bandwidth where none exists.

                           -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Nov 2002 19:44:54 -0500

> 3. jitter ideally should be 0, but up to 60 msec can be tolerated.

It would be useful to get some citations to the published literature
or other more detailed (ideally math) explanations of where those
numbers come from.  I think it would help to be talking about some
concrete numbers.

> in access not on the backbone.

Agree, and please note that the presence/absence of QoS (or bandwidth or
anything else) on the access link is often not under the control of the 
ISP.

> can say, when the access was resolved the backbone was comming along

Sounds plausible enough.

> emergency workers need access too. How can we guaranty that?

It is up to each end site to configure their access router and access 
links
appropriately.  The ISP can't affect much on the last mile access link. 
  Given
the percentage of end sites that don't secure their routers, I would 
rather
rely on Iridium working myself.

Ran
[email-masked]

---

From: Dean <[email-masked]>
Date: Wed, 13 Nov 2002 10:30:00 -0500

> numbers come from.  I think it would help to be talking about some

I have to dig out the test results that we did at my previous
employer. We did internal testing for 4 different codecs
G711
G729a
G723 (ADPCM 32)
G725 (ADPCM 24)

I have to say that the testing was done with our internal sales,
marketing and engineering people. Engineering had a higher tolerance that
sales people.

Different codecs have different network tolerance.

G729a is more flexible on the network, then G711. Here is why:
G729a generates a 10 byte voice frame every 10msec vs
G711 which generates a 64 byte frame every 8 msec. 

Now you can packetize multiple frames into one IP packet. VoIP packets
should be smaller, so that the loss of one (or multiple) packets will
not loose a significant part of the voice information, but also big
enough that jitter in the network can be mitigated.  It is hard to
support, at the access side, an outgoing packet of 48/80 bytes
(G729a/G711 with compressed RTP header) every 8 or 10 msec.  Even in
the backbone, some variations (that will be present in crisis
situations) can cause jitter, which will result in dropped packets at
the destination because the packet(s) timed out.

If multiple voice-frames are packetized (up to a certain point), the
bandwidth requirement for voice conversation will go down (because of
less overhead), but packets are bigger. G729a can grow up to 12 voice
frames per packet (120 bytes + IP/UDP/RTP header) where G711 is
problematic with more than 3 voice frame per packet (192 bytes +
IP/UDP/RTP header).  Waiting for serialization and serialization times
on slower access links impact latency budget for the whole
connection and the interarrival times between packets are still at 24
msec.  If G729a has 4 voice frames per IP packet, we are creating 
more flexible network characteristics for voice conversation.  Every 40
msec one packet of 77 bytes (RTP header compressed to 5 bytes)
is transmitted from the sender, which results in 15.4 kbps bandwidth
per voice call.  Instead of delivering a packet every 10 msec, we can
deliver a packet every 40 msec. If we add a jitter buffer in the picture
the voice frame delivery can be smoothened out.
(usually it is recommended to size the jitter buffer minimum as number
of voice frames per packet + 1 or 2 voice frames, in this case jitter
buffer would be between 40 and 60 msec).

Anyway, I will try to find documents that pertain to your question
(internal test results) and will also try to see what I can find on Google.

However, I believe that GETS service user (e.g., DISA) should tell
this working group what constitues acceptable voice quality (i.e.,
which codecs) and then it would be much easier to specify the
requirements.  For example, cell phones, POTS lines and radio
communications have different voice quality which translates to
different network requirements.

Dean
[email-masked]

===============================================
I like to share my ignorance. I have enough.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 13 Nov 2002 12:32:02 -0500

On Wednesday, Nov 13, 2002, at 10:30 America/Montreal, Dean wrote:
> requirements.

It would be useful to hear what they think.  I'd much rather see
an abstract technical specification than a specification of certain
existing CODECs.  One option of IETF would be for IETF to standardise
a new CODEC (e.g. one that hypothetically would be better suited for
real world deployed IP networks).

Ran

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Wed, 13 Nov 2002 11:19:08 -0800

What's funny is that many of the people who have been defining "voice
quality" in the standards worlds have never had to:

- talked on the phone get next to power generators and coordinate supply
delivery to a disaster area
- talked on the phone on a active evac runway working on eval logistics with
plane take off and landing
- talked on the phone next to a triage site with everyone doing their best
to keep people from dying while there is screaming and shouting trying to
get the work done

This digression on the miniscule percentage of "voice quality" in a WG
looking at insured communications during a disaster is ludicrous.

I say this as I'm talking on a INOC phone with a PG&E generator running next
to my house running device that is blowing out the water from the power
conduit. Volume and a good headset are far more important in an emergency
than a couple of packets being dropped.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> RJ Atkinson
> Sent: Wednesday, November 13, 2002 9:32 AM
> To: Dean
> Cc: ieprep
> Subject: Re: [Ieprep] access links
>
>
>