Subject: Re: [Ieprep] a little homily

From: Fred Baker <[email-masked]>
Date: Mon, 01 Apr 2002 08:30:00 -0800

We certainly need to be able to do our best, and any useful tool to counter 
a credible threat is a good thing to do.

I am going to explain my reasoning with respect to multicast and a special 
multicast group of addresses. Please understand that I am all for multicast 
as a technology, and I am aware of other proposals on the table. These are 
examples, symptoms; I want to use them to address my underlying concern.

Let me give you an insurance analogy. In Florida, one can insure one's home 
and property against a number of threats, including fire and hurricane 
damage. In California, where I live, one can insure one's home and property 
against a number of threats, including fire and earthquake damage. I don't 
know whether they sell earthquake insurance in Florida; I can tell you that 
they don't sell hurricane damage insurance for residences in California. 
The reason they don't sell it is because there is no credible threat - 
that's not a problem we have in California.

Over the past week, we have had a presentation by someone who said he was 
writing a draft about multicast, and we have discussed the possible 
assignment of a set of class D addresses to emergency workers in case they 
can't get them during an emergency.

In the Class D space, there are 2^24 (roughly 16 million) addresses, of 
which 2^20 (about one million) are specified as general multicast addresses 
routable by such protocols as PIM and DVMRP. In the past decade, it is 
unlikely that more than a hundred have been in use at any given time, 
because IP multicast is not heavily used in the commercial Internet, or 
anywhere else. Due to the low level of use, service providers do not 
routinely go to the effort to configure the capability - they don't see 
revenue in response to the effort. The evidence that there is a credible 
threat in the class D multicast address space is not in the least obvious.

And by the way, the folks looking at IP Multicast during an emergency, 
according to all reports, are not emergency workers. Emergency workers 
could presumably use video teleconferencing for certain cases, but in a 
case where we're really happy to be making audio calls work, that's not the 
top of anyone's agenda that has commented to this working group. Emergency 
workers don't use IP multicast, or if they do they haven't bothered to 
report the fact.

So these proposals come:
  - in the complete absence of utility in contemplated emergency communications
  - without any evidence of a credible threat
  - in a widespread absence of commercial deployment
  - when these points were questioned (by me), without even an attempt to
   justify them.

However, if the proposal goes forward, what I hear is a requirement to 
assign addresses that will not be used to applications which do not exist, 
and a requirement for ~10,000 service providers world-wide to expend money 
on infrastructure for emergency communications which will not in fact be used.

This is a waste of money, and an excellent argument for the people who read 
the recommendations of this working group to dismiss them out of hand, as 
silly and ill-considered.

If you want the output of this working group to have an affect, any effect 
whatsoever, on what people do to support emergency telecommunications, the 
output has to be credible, and this is not.

If you want the discussion to be relevant, I have two words for you:

    GGGG  EEEEEE TTTTTTT    RRRRRR  EEEEEE     A     L
   GG GG E         T       RR  RR E         A A    L
   GG     EEE       T       RR RR  EEE      A  A   L
   GG GGG E         T       RRRRR   E       AAAAAAA  L
   GG GG E         T       RR RR  E      A      A L
    GGGG  EEEEEE    T       RR  RR EEEEEE A        A LLLLLLL

Now, we know that in an emergency, a fair bit of traffic can be generated, 
causing a massive and sudden congestive collapse. This can happen in three 
ways:

  - telephone switches (PSTN and IP) can be so overloaded that they are forced
   to ignore calls while they serve the ones they have
  - data application servers can be overloaded to such an extent that they
   are unable to support the load
  - data trunks can be overloaded in such a way that they drop a lot of traffic

We can, realistically, look at the issues in these cases and ensure that 
they are covered. This requires a gap analysis and framework for emergency 
telephone switching; this is a chartered deliverable of this working group. 
It also requires a recommendation for the management of data traffic using 
elastic applications; this likewise is a chartered deliverable of this 
working group.

If there are other credible threats, we need to surface them, and we need 
to make recommendations concerning them.

Interesting solutions that meet no credible threat are out of scope. So any 
proposal of a solution to a problem needs to identify what threat it 
counters, and demonstrate that the threat is credible. Anything which does 
not do so is a waste of all of our time.

I dunno, may you would spend money on Hurricane insurance in California. I 
wouldn't, and I don't want this working group expending time and energy on 
that class of threat.

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

---

From: Alistair Munro <[email-masked]>
Date: Mon, 01 Apr 2002 20:15:29 +0100

Hi Fred,

> elastic applications; this likewise is a chartered deliverable of this

Your comment about the similarity between the requirements of elastic applications
and the availability requirements for emergency traffic (Folt's stated
requirements..) plus other comments under the "public safety"  confirms (if there
were any doubt) that an IP platform should work better than a circuit mode platform
in being able to *place* a vary large number of calls in a very highly congested
situation. However once the call is placed it will generate voice
(elastic/non-elastic - it depends...) and associated data traffic (elastic, IM,
whatever) which must be differentiated for the session end-to-end, where the ends
may be inside/outside the emergency area, in call-centres, at personal or public
phones, Blackberries, etc., etc.

I had been looking at the availability issues for emergency services before this WG
got flowing and was not sure whether the existing IP QoS models were suitable to
support this dense differentiation under the likely traffic load. I do not think
packet marking would be enough to secure the traffic. Id there a specific proposal
yet - I could tell from recent and historical discussion in this group and related
ones?

Regards,

Alistair

---

From: Fred Baker <[email-masked]>
Date: Mon, 01 Apr 2002 11:23:01 -0800

At 11:15 AM 4/1/2002, Alistair Munro wrote:
>packet marking would be enough to secure the traffic.

QoS is not an authentication or encryption technology; IP QoS is not 
designed to "secure" anything.

By this, do you mean that IP QoS is not able to ensure that each individual 
session is able to be guaranteed a specific throughput? What specifically 
do you mean?

---

From: Alistair Munro <[email-masked]>
Date: Mon, 01 Apr 2002 21:10:54 +0100

Hi Fred,

Sorry if this comes through twice in slightly different versions. My server
connection got blasted and I couldn't tell which bit failed.

> QoS is not an authentication or encryption technology;

???? Did I mention security ????

> IP QoS is not

I should have said "secure the traffic", by which I mean "ensure its delivery
according to the QoS requested".

> session is able to be guaranteed a specific throughput? What specifically

I was wondering (a) when a guarantee of throughput was appropriate, (and to
what would it be given), and (b) how one would use the IP QoS model to
differentiate traffic for a very large number of flows and a high local
aggregate traffic intensity (which seemed to be a close model to an emergency
situation). It was a question, not an assertion - I cannot see how.

I am trying to get away from the preemption discussion, which seems to be
soluble, and look at how to keep the traffic flowing while it is being battered
by all the other stuff.

Regards,

Alistair

---

From: Fred Baker <[email-masked]>
Date: Mon, 01 Apr 2002 13:30:00 -0800

At 11:49 AM 4/1/2002, Alistair Munro wrote:
> From what I know of IP QoS, there are mechanisms to guarantee throughput 
> for aggregates and flows. How would they be applied effectively for fine 
> grain differentiation (large number of flows) under very high traffic 
> intensities?

You might read RFC 3246.

Fine grain QoS is a non-goal in IP.

If you trace the signal flow in H.323, the process of setting up a call 
requires something on the order of 50 messages, and that is apart from the 
additional RSVP overhead of ensuring that the call has bandwidth. That 
makes sense if you are setting up shared state which is going to have a 
lifetime of several minutes and will affect O(50) datagrams per second 
while it is set up. It turns out, however, that for Voice or Video on IP, 
one has to ensure that there is sufficient bandwidth for the call, and one 
has to ensure that no call stream over-uses its comitment. Once you have 
done that, you have ensured that each individual flow also has the 
characteristics it needs, and further QoS negotiation is unnecessary - just 
please mark it so that we can police it properly and put it into the right 
queue.

But for elastic traffic, which represents O(95%) of Internet traffic, it 
doesn't make sense. The median TCP session has <= 10 packets going each 
way, and no concept of a rate, as there is only one actual data segment 
each way. To try to set up call state as it exists in the telco world, and 
make "per-call" guarantees, is to dramatically increase the message traffic 
without materially changing much, and even to set up RSVP flow state for 
such sessions is difficult as there is no concept of a rate - and the guy 
requesting the rate has no concept of the amount of data he is asking for.

So we actively avoided the question for elastic traffic, and in the case of 
inelastic voice/video traffic, enable you to negotiate the bandwidth using RSVP.

---

From: Scott Keagy <[email-masked]>
Date: Mon, 01 Apr 2002 16:39:51 -0800

Relevant problem: Let emergency-related IP packets through a congested network.

Proposed solution: use WRED to deal with congestion scenarios, with no 
drops of emergency-related IP packets (even though UDP and short TCP 
sessions won't throttle back).

How it solves/addresses the problem:
1) doesn't require signaling ahead of time like RSVP (which can delay the 
session setup and be a processor/memory burden on congested boxes)
2) simple mechanism to let emergency-related IP packets through during 
congestion
3) May not help alleviate overall network congestion condition (and may 
actually make it worse if many UDP applications retransmit on delivery 
failure- not an issue for real-time apps), but it will certainly get 
emergency traffic through with greater reliability.
4) Delay/jitter performance for real-time emergency apps won't suffer much 
(from not getting moved to the front of a queue) unless there are huge 
buffer queues in high bandwidth interfaces; low-bandwidth links will 
absolutely require packet prioritization to solve delay/jitter performance 
issues.

Regards,
Scott

At 01:30 PM 4/1/2002 -0800, Fred Baker wrote:
><snip>
>make "per-call" guarantees, is to dramatically increase the message 
>traffic without materially changing much, and even to set up RSVP flow 
>state for such sessions is difficult as there is no concept of a rate - 
>and the guy requesting the rate has no concept of the amount of data he is 
>asking for.

---

From: Fred Baker <[email-masked]>
Date: Mon, 01 Apr 2002 17:14:25 -0800

that actually sounds a lot like section 2.4 of 
http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt, 
which describes classes of traffic in the diffserv architecture and how 
they might be used. What would be necessary would be to ensure that traffic 
marked with the higher drop probabilities never included emergency traffic; 
we would need to discuss how that might be achieved. The adoption of RFC 
3168 would make it a lot easier, as apart from the open SYN/SYN-ACK packets 
it doesn't drop traffic in response to congestion, it marks it as having 
experienced congestion.

At 04:39 PM 4/1/2002, Scott Keagy wrote:
>>> From what I know of IP QoS, there are mechanisms to guarantee 
>>> throughput for aggregates and flows. How would they be applied 
>>> effectively for fine grain differentiation (large number of flows) 
>>> under very high traffic intensities?
>>
>><snip>
>>
>>each way. To try to set up call state as it exists in the telco world, 
>>and make "per-call" guarantees, is to dramatically increase the message 
>>and the guy requesting the rate has no concept of the amount of data he 
>>is asking for.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 01 Apr 2002 22:38:22 -0500

On Mon, 01 Apr 2002 16:39:51 -0800
> through a congested network.

Dear Scott;

   I am afraid that I do not understand how this is supposed
to work.

RED and WRED drop packets early to "alert" TCP of upcoming
congestion. I am guessing that you mean to not subject the
"emergency" packets to the early loss procedures. But

1.) how do you let routers know which packets are
"emergency" ? and

2.) When the congestion occurs, the packets have to be lost
for real. What happens when "emergency" packets are received
without room in the queue ? Are there separate queues for
the "emergency" packets ?

3.) What is the authority for setting emergency packets ?
How is this information propagated ?

I do not understand how you could avoid the complications of
RSVP, or even why this would be superior.

Regards
Marshall Eubanks

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 02 Apr 2002 01:35:03 -0500

Dear Fred;

I thought I should respond to this.

I first became aware of this WG in the run up to the last
IETF. After 9/11, I became part of a working group in the
International Webcasting Association, seeking to publicize
the useful of multicast videocasting (i.e., webcasting) in
emergency situations. The charter of this WG states 

-The working group will develop a BCP RFC or set of RFCs,
-regarding operational implementation of services for
-Emergency Preparedness using existing Internet protocols.

which seems to render on topic not just the hardening of
existing and wide-spread applications, such as e-mail, but
also consideration of relatively new applications such as
VOIP and multicast, and how they might relate to emergency
communications. As I have been working on such matters since
October, I thought that I might be able to contribute to the
WG, not just on matters multicast, but in general. It was
certainly not my intention to stir up any trouble.

However, we have been discussing the application of
multicast to emergency communications, and, as such, this
seemed and still seems relevent to the charter of this
working group.

On Mon, 01 Apr 2002 08:30:00 -0800
> threat in the class D multicast address space is not in

Multicasting has a working address allocation system which
is actually considerably used - the RFC 3180 "GLOP" address
space. Most of the 1 to 3 thousand "permanent" groups that
have been present in the last year have group addresses
coming from this range.

Perusal of the multicast status page that we maintain

http://www.multicasttech.com/status/index.html

shows that multicast deployment is of order 5 to 15% of the
entire Internet. Perusal of the multicast AS list 

http://www.multicasttech.com/status/mbgp.sum

shows that most of the "backbone" providers have at least
some support for multicast.

I do not think that it is the job for the IETF or a WG to
tell ISP's to adopt multicast, any more than for any new
technology. However, it is germane to say that certain
technologies are better or worse for certain applications
under certain circumstances, and that, in the proper scope,
it seems to me fails squarely in the working group charter.

> workers don't use IP multicast, or if they do they

I do not see that this is germane. I am sure that they
are not, by and large, aware of multicasting. They are not
aware of VOIP either, nor of the differences between packet
and circuit switching. That is our job, not theirs.

The charter for this WG talks about the  rapid evolution of
the "commercial telecommunications infrastructure" to the
Internet, which implicitly, at least, includes video. The
emergency workers that I have talked to have expressed
interest in Internet video (as in video from the scene,
rather than videoconferencing). This is, by and large, a new
capability for them. I feel certain that this technology
will be used as it becomes available and wireless packet
switched communications becomes more ubiquitous. So I would
certainly regard recommendations by the working group as to
what sort of video transport is suitable as consistent with
the charter of the WG.

Finally, communications between the emergency infrastructure
and the populace are certainly part of emergency
preparedness. Again, I would regard recommendations by the
working group as to the best way to do this as consistent
with the charter of the WG.

> wouldn't, and I don't want this working group expending

I have no intention in further describing multicast
technology or deployment in this list except as is relevant
to future discussions (I would be glad to respond to
questions or comments either off list or on MBONED, if
anyone wants to pursue them). However, I thought that it
might be useful for me to comment upon certain of the issues
raised in your previous e-mail as to the scope of the WG. If
the working group and the area chairs feel that the scope of
the WG is indeed limited to the telephony aspects of
telecommunications, then so be it. 

Fond Regards
Marshall Eubanks

---

From: Alistair Munro <[email-masked]>
Date: Tue, 02 Apr 2002 17:18:30 +0100

Hi Fred,

> Fine grain QoS is a non-goal in IP.

Goal or not, it is possible according to RFC 3246. However, I don't know 
if the strategies indicated in RFC 3246 would meet the requirements of 
 IEPREP if one were to grub around inside the aggregate. RFC 2998 gives 
a better big picture IMO. However the main issue is that we expect to be 
operating at an extreme of traffic intensity at which point RED may 
start to have an effect too.

The outline configuration you propose in  
http://www.ietf.org/internet-drafts/draft-baker-ieprep-requirements-00.txt 
, section 2.4, would disadvantage some signalling traffic. I would put 
signalling related to voice/video set-up (H.323, SIP) in AF4. As it 
happens, in my (admittedly small but deliberately overloaded) 
voice/video network, I put signalling and call traffic (inc. in-band 
RSVP) in two EF aggregates (signalling given a higher quality service) - 
I believe that putting it in AF3 runs the risk of losing it or demoting 
it further. In conditions of heavy congestion anything in the lower 
ranks of AF will suffer.

The configuration would be fine I think for a purpose built IP emergency 
network but not for a multi-service public ISP. I am not keen on adding 
codepoints to differentiate emergency traffic for the latter case and, 
from previous comments, I'm not sure if the latter is being considered 
or not.

> If you trace the signal flow in H.323, the process of setting up a 
> call requires something on the order of 50 messages, ....
> So we actively avoided the question for elastic traffic, and in the 
> case of inelastic voice/video traffic, enable you to negotiate the 
> bandwidth using RSVP.

Not sure about all this other stuff - tutorial or not, it may, or may 
not, be needed as we examine the requirements in more detail. I hope 
not. The number of messages exchanged by H.323 or SIP is a fact, to be 
taken into account because we will be using one or the other or both. 
TCP rate control by bandwidth limiting or ECN may be useful in the 
IEPREP, or not - I don't know if the 95% status-quo of short 
transactions will apply at this stage. Again, I suspect, and hope, it 
will as the damage may have been done by a long-lived TCP "session" by 
the time edge-mechanisms kick in.

Regards,

Alistair

-- 
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.degree2.com, http://www.u4eagroup.com

---

From: Fred Baker <[email-masked]>
Date: Tue, 02 Apr 2002 11:42:54 -0800

At 10:35 PM 4/1/2002, Marshall Eubanks wrote:
>If the working group and the area chairs feel that the scope of the WG is 
>indeed limited to the telephony aspects of telecommunications, then so be it.

the working group is not limited to the telephony aspects. It is, however, 
chartered to write requirements targeted at solving problems that are 
preventing the Internet from being used in an emergency services 
infrastructure, not to be a fishing expedition.

Let's take Ken's comment yesterday, that multicast might be useful for VoIP 
and video on IP for emergency workers. VoIP has certain requirements for 
emergency workers, in the sense that if there is a choice between a VoIP 
call that will help manage the emergency getting through and some other 
call getting through, one wants the emergency-useful call to go through. 
VoIP-for-emergency also has all the usual issues of VoIP - the QoS better 
be there, by whatever means.

Now, when we want to have a teleconference among various people at 
disparate locations, we will want to use multicast routing to do that. But 
the issues here are not for multicast per se, they are for the voice/video 
application that happens to be in use, and they are the same issues as 
apply to point to point calls.

So, with anything we discuss, the point in *this* working group needs to be 
the coupling of a problem and a solution, not just "I have a great idea." 
With a million addresses available to be used at any given time, and by 
your estimate a few thousand actually in use, I don't see a problem.

We're here to do solid engineering, not marketing. We're asking people to 
spend money; there better be a bang we get for those bucks, or the bucks 
will not be spent and we will be deemed irrelevant. That's my point.

---

From: Fred Baker <[email-masked]>
Date: Tue, 02 Apr 2002 12:00:18 -0800

At 08:18 AM 4/2/2002, Alistair Munro wrote:
>signalling related to voice/video set-up (H.323, SIP) in AF4.

I'm confuse by this statement.

AF is defined by http://www.ietf.org/rfc/rfc2597.txt, which I would 
encourage you to read. It defines four classes of traffic, which a network 
administration assigns bandwidth to individually.

If I have a video stream which will average 7 MBPS, let's say, I would tag 
it as AF4 (I would give it the AF41 code point, and a subsequent metering 
point might re-assign any traffic over 7 MBPS as AF42, but they would go 
through the same queue), and I would provision the queue to handle >=7 MBPS.

If I am provisioning the network for 100 simultaneous VoIP calls, and each 
call occupies (let's say) 90 KBPS of IP traffic, I would also provision a 
priority queue (as opposed to a rate-based queue) into which I would put 
the EF traffic, and I would police the input to that queue, dropping 
traffic in excess of 9000 KBPS (9 MBPS) in either direction on a link; I 
would also want an RSVP registration of the bandwidth.

Suppose that the network administration measures that there is a standing 
load of 100 KBPS of signalling traffic going along with the AF4 and EF 
traffic. I would expect it might provision the AF3 queue to have 250 KBPS 
of capacity for same. The net result would be that little if any signalling 
traffic is delayed, much less dropped, even if AF4 is getting completely 
hosed, and even if we are refusing calls to place traffic into the EF 
queue, because the 250 KBPS traffic bound is not being crossed.

The different diffserv classes are as separate as if they were on separate 
lines, except for the fact that if one is not using its bandwidth at the 
moment the other might temporarily use it.

>  As it happens, in my (admittedly small but deliberately overloaded) 
> it further. In conditions of heavy congestion anything in the lower ranks 
> of AF will suffer.

Your comment leads me to believe that you are under the (unfortunately 
common) misunderstanding that the classes of traffic are somehow 
priorities, and that AF4 would therefore shove AF3 out of the way. Are you 
under this misunderstanding? That's not how rate-based policies work.

---

From: Scott Keagy <[email-masked]>
Date: Tue, 02 Apr 2002 14:39:44 -0800

responses in-line

>"emergency" packets to the early loss procedures. But

Yes, selectively discard flows based on classified traffic. Example would 
be to let general HTTP / FTP traffic get progressively increasing drop 
rates based on increasing buffer depth thresholds, while emergency traffic 
is not dropped at all.

It is primarily used to make TCP sessions back off and use slow-start 
mechanisms, but it can be useful as a low-overhead simple way to let 
emergency traffic through high bandwidth interfaces without regard to its 
impact on TCP backoff/slow-start or UDP impacts. The underlying principle 
in this approach would be "I'm not really trying to optimize congested 
network throughput, I'm just trying to make sure emergency services are fine".

As I thought about this more, and about interaction with real-time apps 
(like telephony) that also would require preferential treatment with WRED, 
I convinced myself that prioritization of real-time emergency services vs. 
real-time normal services should not happen at packet level, but rather at 
call-control / session-control level (which has been discussed a lot 
earlier in this group).

If you really want to stick with a packet-level approach for real-time 
services, then maybe set up normal voice services (and other real-time 
stuff)  to get dropped only at high buffer depth thresholds, while 
emergency traffic is not dropped at all.

Dropping plan would look something like this:

                                 Drop rate       Drop rate       Drop rate
queue depth             (normal)        (real-time)     (emergency)
=========               ======= ========        =========
25%                     50%             0%              0%
50%                     80%             0%                      0%
75%                     95%                     50%             0%
90%                     100%            75%             0%
99%                     100%            100%            0%

This is a gross oversimplification of queue depth ranges, and completely 
inaccurate/unverified  drop rates, but it gets the concept across

>1.) how do you let routers know which packets are

That is a separately scoped problem, with one potential solution being the 
use of DSCP marking. (other issues include trust of entity marking the 
packets but this is part of the "identifying emergency flows" problem").

>the "emergency" packets ?

That is the whole point of RED and WRED: proactive queue depth management. 
If WRED is working right, you should *never* have a full queue, so 
emergency traffic never faces this scenario. For a detailed discussion of 
this topic, check these links:
         http://www.icir.org/floyd/red.html

I also talk about it from a variety of perspectives in "Integrating Voice 
and Data Networks"
  (link to appropriate table of contents section):
         http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/1578701961/reader/8/
         (please excuse the blatant self-marketing)

>How is this information propagated ?

Again, this is separately scoped issue.

>RSVP, or even why this would be superior.

I'm not trying to bring an end to RSVP. I'm just suggesting an alternative 
approach to explore; on this list we should find holes in this suggestion 
which would still require a more complicated solution (like RSVP).

Regards,
Scott

---

From: Alistair Munro <[email-masked]>
Date: Wed, 03 Apr 2002 09:06:33 +0100

Hi Fred,

> apply to point to point calls.

Group calls and press-to-talk are key emergency service applications supported by
layer 3 multicast in professional land mobile services. Attempts to do it at layer
7 in circuit switched networks such as GSM have succeeded but are expensive in
resources and erratic in availability. It is natural to use IP multicast to
support these applications.

Users will compromise on voice quality as long as they remain in contact and get
something through. Best effort is not good enough in principle but will work up to
a point. Some bandwidth has to guaranteed under congestion - I did some
qualitative experiments which suggested I could tolerate about 10 Kbps per
conversation.

Regards,

Alistair

---

From: Alistair Munro <[email-masked]>
Date: Wed, 03 Apr 2002 12:50:12 +0100

Hi Fred,

Thanks for the AF tutorial.

> ranks
My "understanding", please question it, is that EF and AFn are 
distinguished by their forwarding behaviour. I don't see where priority 
comes in. It wouldn't be a useful discriminator in the congested 
situation especially, nor indeed anywhere, or at all in my experience - 
it is quality that is the discriminator, as I see I said above. 
Something has to give under congestion and putting things in EF gets 
them in and out as smartly as possible.

Regards,

Alistair

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 03 Apr 2002 10:22:45 -0500

> qualitative experiments which suggested I could tolerate about 10 Kbps per

I can agree with your statement that IP multicast is very efficient
for key applications, but I am wondering on how much voice quality
degradation users are willing to compromise, because voice quality in
emergency situation is very important. Usually in emergency situations
noise level is pretty high, so lower voice quality might lead to
harder understanding between emergency workers.
I do not know how did you calculated the 10kbps per conversation,
because I do not know the other parameters. In voice packetization
there are two key parameters:

1. voice compression
2. number of voice frames per 1 datagram

This two parameters will give us the bandwidth requirements, but also
will influence the voice quality. Here is an expample
1st voice call is using ADPCM24 codec and 2nd voice call is using G729a
codec.
ADPCM generates every 8 ms 1 voiceframe of 24 bytes. To that we have
to add IP and UDP and RTP headers. If 4 voice frames are packetized in
one datagram, each datagram is carrying 32ms of voice.

G729a generates every 10 ms 1 voiceframe of 10 bytes. If 4 voiceframes
are packetized, each packet is carrying 40 ms of voice. 

With adding more voiceframes per 1 datagram (to a certain number) the
bandwidth requirements are going down, but the voice quality can be
impacted depending on the network congestion and the packetloss. Also
with increasing the voiceframes per 1 datagram the latency
requirements are more elastic, but the packetloss will have a higher
impact on the voice quality

Also using header compression algorithms are inducing more latency to
the process and there is a fixed latency bugdet. If the latency is
bigger than the budget the voice queue is starved (because late
packets are dropped from the voice queue).

And the last one is voice quality perception. What you or me accept as
OK, other people might not.

I believe that bandwidth requirements for voice calls have to be
better investigated.

I like the idea of using IM as emergency service, because it has voice
and data capabilities. One additional feature to IM, could be voice
recognition sw. I believe that hearing and reading sent information
can help in emergency situations. 
There are number of possibilities to offer various IM sessions types:

1.high quality voice conversation - real time requirements (PSTN like)

2.high quality voice conversation - non real time (like IM, messages are
replayed after the whole data is delivered, this gives only simplex
communications, but eases the requirement on the network, because data
can be resend to a certain extent. Voice recognition sw can be used
here for text output, which helps a lot in noise enviroments. How
often emergency workers have to repeat informations over radio
stations because of noise or bad reception)

3. text only

etc.

--br

Dean

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 03 Apr 2002 16:40:11 +0100

> OK, other people might not.

see the following for a couple of perspectives on user tolerance of 
loss/delay for VoIP traffic.

  http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip
  http://www.cs.ucl.ac.uk/staff/A.Sasse/inet95audio.ps

the above does not provide a definitive answer, just some insights.
and as previously stated, your mileage may very depending on the Codec 
in use.

-ken

---

From: Fred Baker <[email-masked]>
Date: Wed, 03 Apr 2002 09:22:23 -0800

At 03:50 AM 4/3/2002, Alistair Munro wrote:
>distinguished by their forwarding behaviour.

I believe that this is wandering fairly far afield, but I'll try to answer 
the questions in the hopes that we can eventually get back to our chartered 
tasks. Since diffserv is a data plane technology, the only thing the can 
talk about is what happens to packets in flight. Is that what you mean by 
"forwarding behaviour"?

>  I don't see where priority comes in.

Suppose you are at the airport trying to check in. There is a grand total 
of one person checking people in and taking their baggage, at your favorite 
airline, but there are two lines - the first class line and the line 
everyone else is in. The clerk operates on the rule that "if anyone is in 
the first class line, serve them, and only serve 'everyone else' if there 
is nobody in the first class line".

The clerk is acting as a 'scheduler', and the lines are (obviously) 
'queues'. The rule by which the clerk operates is called a 'scheduling 
discipline'. This particular scheduling discipline is called 'priority': 
the first class line experiences relatively little delay, and relatively 
little variation in delay, because the clerk is taking them first. All of 
that delay is transferred to "everyone else".

Now, let's make life more difficult for our overworked clerk. "Everyone 
else" is divided into four lines in some fashion, perhaps by the color of 
shirt they are wearing that day. You said yesterday that you were concerned 
that AF3 would get overwhelmed by AF4, since AF4 is a busy class. This 
would be analogous to telling the clerk "take anyone in first class, and 
absent that, take from general access line 4,, and failing that take from 
general line 3, and so on." This scheduling discipline is a generalization 
of priority with multiple levels of priority. As you say, if we follow a 
priority discipline, and one line is taken before another, eventually 
something "has to give", and it might well be the people in the lowest 
priority line.

But suppose instead that the four lines that "everyone else" is located in 
get some form of round robin discipline. The clerk is told:

         "spend one minute serving people from line 1,
         then spend five minutes serving people from line 2,
         then spend two minutes serving people from line 3,
         then spend eight minutes serving people from line 4.

         If at any time someone shows up in the first class line,
         take them next, but do not account the time spent serving
         them against whatever line you happen to be serving;
         when you can, return to that line and keep going.

         If the line you are operating on goes empty, do not take a
         break; instead, start the time for the next line."

That is clearly a little more complex. What we have is four rate-based 
queues, with different 'weights', and the scheduling discipline is a 
variation on one called 'weighted round robin'.

What's going to happen? Well, suppose that people are arriving at line 4 at 
approximately the rate it is being served. What is going to happen to them 
is that they may wait a while in queue, but they will in fact get served. 
If people are arriving at line 2 far more rapidly than it is being served, 
people will eventually decide that the wait isn't worth it, and go do 
something else. They will be "dropped". If people are arriving at line 1 - 
which has very little resources allocated to it - significantly less 
rapidly than it is being served, they will often walk up to an empty line, 
wait a few minutes for the line's turn, and then get served.

Of course, the first class line is still getting excellent service.

What I have just described is one way to implement EF and AF in a router 
scheduler; there are other, more complex, algorithms for dealing with the 
AF classes. But the effect is similar - each queue gets a service rate, and 
the delay and drop characteristics are largely independent of the other 
queues - it depends mostly on the arrival and departure rate of elements in 
the queue you are worried about.

>Something has to give under congestion and putting things in EF gets them 
>in and out as smartly as possible.

yes, and for traffic that has that requirement - voice - that is the right 
thing to do. Elastic traffic (of which TCP-based internet applications are 
examples) doesn't have an "as little jitter as we can manage" requirement; 
that's part of the meaning of the word 'elastic". It does have a 
requirement for a certain average rate of service, but that rate can be 
very low, on the order of seconds to tens of seconds between events. What 
it *does* require is that whatever rate it gets it gets fairly consistently.

The fact that instant messaging worked on 9/11 is evidence that this works 
quite well under load.

---

From: Fred Baker <[email-masked]>
Date: Wed, 03 Apr 2002 09:26:17 -0800

>I believe that bandwidth requirements for voice calls have to be

Like you, I have a hard time imagining why voice calls in emergency 
situations are significantly different than voice calls any other time. We 
have spent the past decade making voice work well in Internet technology; 
what we want to discuss here is how to use the technology, not how to 
engineer it.

Hence my comments about engineering it using multicast. Certainly one can 
do that, but multicast doesn't impose requirements on us, it is a way to 
meet the requirements.

I would really like to get back to the chartered work of this working 
group, which is describing requirements and making recommendations for 
emergency use of internet technology.

---

From: Alistair Munro <[email-masked]>
Date: Thu, 04 Apr 2002 09:52:24 +0100

Hi All,

> situations are significantly different than voice calls any other time.

I am following the charter, I think, in trying to identify current (best)
practice. The remarks were intended to provide information on that.
Specifically:

1. On diferences in expectation of quality, I speak only from experience,
input received from PMR users and equipment vendors, and listening tests with
around 500 subjects using recorded data from the UK MPT1327 system.

2. The 10 Kbps claim is not calculated but based on listening tests using a
standard H.323 VoIP handset, G.711 codec, EF forwarding (roughly) with a delay
across the network element of about 74 usec per byte, offered load about 200%
of the element's forwarding capacity. I was not able to measure the loss at
the phones if any - most frames were discarded by the network element. The 10
Kbps is not representative of the technology that emergency services use but
speech was intelligible.

3. Typical PMR codecs run in 6.25 Kbps - there is a significant difference in
the delivered service from the one Joe Public would get when he makes a 911
call from his cellphone/PDA/whatever.

The observation was intended to be a response to Fred's remark that quality is
essential - yes, it is but knowing more about current practice will affect the
constraints on the protocols that we specify for the congested situation. I
wouldn't want to specify codecs, but as we are providing information about
deployment issues, we ought to draw attention to current practice and effects
of loss and delay. As Dean noted, I think, this is a complex topic.

> emergency use of internet technology.

I see multicast as an essential part of the solution. Current practice for
using multicast in interactive real-time applications is a mystery to me. I do
not think that oversubscription of the multicast address space will ever be an
issue. Scalability and reliability requirements may point us to specific
multicast protocols. I have no idea about routing.

Are we going to write applicability statements (although not currently in the
charter as far as I can tell)? If we are, then these discussion seem to me to
indicate non-requirements quite well.

Regards,

Alistair

---

From: Alistair Munro <[email-masked]>
Date: Thu, 04 Apr 2002 14:35:22 +0100

Hi Dean,

> I believe that bandwidth requirements for voice calls have to be

As a general comment, codecs used in professional systems require less bandwidth
(6.25 Kbps for example); some GSM codecs go lower. I believe the driver for this is
to squeeze as many calls as possible into what is often very limited overall
bandwidth. If we are going to use IP on these platforms, which seems to me to be a
good idea, then the current emergency service practices must be explained and
compared with practices used in deployment of fixed network IP voice solutions.

> can help in emergency situations.

Messaging services for downloading pictures, fingerprints, audio-clips, etc., etc.
have been used for over 15 years, so IM seems a good candidate as a solution to
support this application. However instant means INSTANT. I am not aware of
applications based on two-way IM-like services.

Regards,

Alistair

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 04 Apr 2002 15:08:43 +0100

hi,

> As a general comment, codecs used in professional systems require less 
> bandwidth (6.25 Kbps for example); some GSM codecs go lower. I believe
> the driver for this is to squeeze as many calls as possible into what is
> often very limited overall bandwidth. If we are going to use IP on these 
> platforms, which seems to me to be a good idea, then the current
> emergency service practices must be explained and compared with practices 
> used in deployment of fixed network IP voice solutions.

could you elaborate and be more specific by what you mean by the term 
"current emergency service practices"?  

> Messaging services for downloading pictures, fingerprints, audio-clips,
> etc., etc. have been used for over 15 years, so IM seems a good candidate
> as a solution to support this application. However instant means INSTANT.

perhaps it depends on how you define "INSTANT".  the end-to-end delay of
IM text messages via propagation and/or retransmission delay are not as
stringent as that expected of interactive voice.  so if it takes in the
order of seconds to send a line of text for IM, thats fine, and that
why folks have a habit of chiming in saying "use IM, problem solved :-)".
i don't mean to imply that is what you're saying, but simply that IM
(at least in text form) is a type of elastic application that can tolerate 
relatively high levels of loss and delay and yet still operate well enough
for a user.

> I am not aware of applications based on two-way IM-like services.

whats a "two-way" IM-like service?  we have had unix "talk" for a loooong
time.  the IM craze simply made the presence of others a bit easier to
figure out.

cheers,

-ken

---

From: Alistair Munro <[email-masked]>
Date: Thu, 04 Apr 2002 17:53:29 +0100

Hi Ken,

> "current emergency service practices"?

I meant the specific codecs, sampling rate and sample sizes, toleable error
rates, etc. Why? To give guidelines on deployment and possible bandwidth
allocations. I don't care waht they use but we should be able to say what *not*
to do if the applications are going to work.

> relatively high levels of loss and delay and yet still operate well enough

A few 10s of seconds for a picture at reasonable resolution of a key
person/suspect - finger in the air here I'm afraid.

> time.  the IM craze simply made the presence of others a bit easier to

I referred to a comment from Dean, I think, who mentioned the possibility of
holding a voice conversation using IM. I think this is a bit on the edge and
may well not solve a problem for anybody.

Regards,

Alistair

---

From: Fred Baker <[email-masked]>
Date: Thu, 04 Apr 2002 09:48:23 -0800

>indicate non-requirements quite well.

for the moment, let's restrict ourselves to the charter. If we have 
specific requirements of voice, including that it (a) be understandable and 
(b) that it be possible to set up teleconferences of a certain size, that 
sounds like requirements. Let's leave the solutions to those problems to 
the groups working on those problems.