Subject: RE: [Ieprep] Multiple instances of EF

From: "Nguyen, An" <[email-masked]>
Date: Wed, 23 Jul 2003 11:07:11 -0400

Ran,

Question for clarification: EF is for voice bearer. What about voice-related
signaling streams? How are they handled at the routing layer? 

Thanks,

An

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Wednesday, July 23, 2003 10:35 AM
To: [email-masked]
Cc: ieprep
Subject: Re: [Ieprep] Multiple instances of EF

On Wednesday, Jul 23, 2003, at 09:31 America/Montreal, [email-masked] 
wrote:
> Guess I'm thinking of the use of the multiple queues for voice, since
> that was the subject here (emergeny calls). While it is true that the
> lower "priority" queue could meet the criteria for EF for some other
> constant bit rate service with much less stringent delay requirements, 
> I
> don't believe it could meet the requirements for voice.

I know of deployed DoD voice/IP applications whose requirements
are well below even needing *any* form of DiffServ, so I do not
believe the claim that only one queue of EF will meet 'voice
requirements' is very generally true.

The claim might be true for some particular vocoder algorithm,
though no particular algorithm or other qualification was made
clear in the quoted text.   To some of us, such a lack of
resilience would be a large clue to use a different vocoder
algorithm.  A number of ITU-T vocoder algorithms appear to
lack resilience -- not surprising since many (all ?) of them
were designed for the circuit-switched phone system.

Folks here might really want to grab a copy of NRL's Ivox
and play with it.  It has a range of vocoders (several
proprietary to DoD).  The software is freely available
for a number of OS/CPU platforms and it works quite well.
(Google for "NRL IVOX" and you should turn it up :-).

Cheers,

Ran

_______________________________________________
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: RJ Atkinson <[email-masked]>
Date: Wed, 23 Jul 2003 12:58:20 -0400

On Wednesday, Jul 23, 2003, at 11:07 America/Montreal, Nguyen, An wrote:
> Question for clarification: EF is for voice bearer.
> What about voice-related signaling streams?
> How are they handled at the routing layer?

Any or all configuration of "active queuing" [1] is a
decision made individually by each network operator.

IETF normally does not try to tell any network operator
how to configure, deploy, or operate their network(s).

So those streams could be handled in any way that the operator
chose to configure their network.  If the question is
about what options exist, I address that in more detail
below.  If the question is about what is deployed, the
operators are in a better position to talk about that.

QoS capabilities of networking equipment (e.g. switches,
routers) varies a great deal.

Equipment built on commodity switch/router silicon
(e.g. inexpensive stuff bought at retail stores) often
looks more or less like this:
	- one queue per port (i.e. no QoS)
	- two queues per port (i.e. very limited QoS)
	- no 'packet classification' [2] capability
	  or very limited packet classification capability
	- only one form of queue management available
		(WFQ might be most common)

Equipment built on vendor-designed proprietary silicon
(e.g. Extreme, Juniper) often has more capabilities:
	- 4 or 8 queues per port
	- ability to classify packets/frames based on
	  multiple header fields such as
		- 802.1p precedence
		- IP ToS byte
		- IP Addresses (source &/or dest)
		- upper-protocol (TCP, UDP, SCTP)
		- application port (source &/or dest)
	- multiple queue management algorithms
		(WFQ, RED, & WRED are all pretty common)

	The ability to (re-)mark the IP ToS byte or 802.1p
precedence field based on classification is not uncommon,
but is certainly not available in all current equipment.

	In the more QoS-capable equipment, it certainly would be
possible to classify any traffic that used predictable
port/protocol combinations and either raise or lower the
priority of that traffic, subject that traffic to active
queuing, mark IP ToS/802.1p precedence bits, or otherwise
apply QoS to that traffic.

	Operators likely would want to test the behaviour of
equipment before selecting it for deployment and before
enabling or configuring QoS on that equipment, of course.

[1] Meaning DiffServ of any type, Class-based Queing in routers,
or anything similar that uses more than one queue per port
and some form of queue management.  Commonly implemented
queue management techniques include WFQ, RED, WRED.
[2] Packet Classification normally means the ability to
look at a packet (or frame in the case of an L2 switch),
the header fields, and then sort the packet (or frame) into
the appropriate queue (possibly including re-marking the
IP ToS byte or 802.1p precedence field as well).

	Personally, I think the notion that 'only EF is suitable
for voice' is confused at best.  My own experience is that
one can configure DiffServ in such a way that it is not really
terribly useful for anything -- and also that one can configure
DiffServ so that it adds a lot of value.  I think too much
attention to EF or AF (or other PHB) often can confuse the
issues rather than simplify them.  I've seen AF-compliant
queuing used with voice -- and work well.  I have also seen
EF-compliant queuing used with voice -- and work poorly.

	The DoD reportedly has had significant experience with
the IP precedence values defined in RFC-791 -- and as near as
I've heard that worked well (and occurred before the IETF
even created a DiffServ WG).  As far as I know, most of that
experience was on Proteon boxes -- whose OSPF supported
ToS-based path selection (e.g. so delay sensitive traffic
would use undersea cable between JP and US, while some other
traffic would tend to go via SATCOM).  I think that the
ACC boxen might also have supported those OSPF enhancements,
but I'm not certain.

Ran Atkinson
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 23 Jul 2003 13:09:27 -0400

On Wednesday, Jul 23, 2003, at 12:58 America/Montreal, RJ Atkinson 
> apply QoS to that traffic.

One challenge to ISPs that use the above approach to classify
traffic for certain port/protocols (e.g. telephony signalling)
would be that individuals using other applications (e.g. multimedia
file-sharing applications) would probably configure their
applications to use those same port/protocol values in order
to obtain the preferred service for non-legitimate traffic.

That is a kind of denial-of-service attack, one that has
been discussed various places (e.g. IEPG) in the past.

A second challenge is that if a backbone is typical --
and is over-provisioned -- then traffic that is queued
specially could well have worse performance/QoS results
than the best-effort traffic.  This is a counter-intuitive
result, but has been reported as experimental result in
some cases (again, this was from an in-person discussion
at an IEPG meeting a while back).

So it is really not clear that there would be benefit to
deploying any of this QoS stuff in an inter-domain context.

Within a single administrative domain, the operator could
theoretically force applications to only use protocol/port
combinations that were approved by the powers-that-be for
that administrative domain -- though this could be pretty
hard to achieve in practice if one's domain had significant
deployment size.

Cheers,

Ran Atkinson
[email-masked]