Subject: RE: [Ieprep] problem context

From: "Choi, Don" <[email-masked]>
Date: Wed, 27 Nov 2002 11:37:03 -0500

Ran,

It is not what I want, nor what the DISA Center for Standards wants, nor
what DISA wants, it is what DoD wants. And it is not just U.S. DoD, but our
counterparts in many other countries. 

What DoD wants is, simply put, when a mission critical user makes a call,
the call goes through and stays up. It does not say calls have to be
pre-empted nor packets should be dropped. It happened that in a circuit
switched network, pre-emption was the chosen solution for this requirement.
So, MLPP is a SOLUTION for this requirement in circuit switched networks,
not a requirement. Even in circuit switched networks, there had been
proposals to support this requirement without using preemption.

It has been a policy of the current U.S. administration and the previous
administration to use products and services based on commercial standards,
not based on military standards. And the current administration wants
IP-centric solutions for our needs. So, it is of critical importance that we
(DoD) have commercial stantandards for IP-based solutions that support our
requirements. And we (DISA) think that IETF is the place to develop these
standards. 

An alternative to this, if IETF can not develop such standards for some
reason, is military standards developed by a dumb guy like me. This
alternative does not serve anyone, tax payers, the administration, DoD and
the internet community. 

We are not saying the Internet has to support this requirement. This
requirement is applicable only to the products and services to be sold to
DoD, and hopefully to our counterparts in other countries. The current
international situation calls for not just interoperability within DoD, but
combined interoperability with our allies and partnership countries.

Have a great Thanksgiving.

Don
-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 4:44 PM
To: Scott Bradner
Cc: ieprep
Subject: Re: [Ieprep] problem context

On Tuesday, Nov 26, 2002, at 16:25 America/Montreal, Scott Bradner 
wrote:
>> Along those lines, I don't think the goal of an MLPP service is to
>> throw away bits according to diffserv-style priorities.  I think 
>> levels
>> in a scheme like MLPP only make sense in an application specific
>> context, possibly only in the context of audio media even....
>
> I expect you are right

	MLPP as implemented today in DSN ("AutoVon") actually throws away
existing live calls (the "pre-emption" part) if a trunk is out of
capacity and a higher precedence call appears on the scene.  MLPP
as formerly implemented in some DoD IP networks (~10 years back)
dropped lower precedence packets in order to avoid dropping higher
precedence packets when a link was underprovisioned relative to
offered load.

	It would be useful if Don would clarify more precisely what he
is looking for.  It could be either the quoted approach up top,
my (poor quality) summary of current/past DoD deployment, or something
else entirely.

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: Bill Woodcock <[email-masked]>
Date: Wed, 27 Nov 2002 09:31:05 -0800 (PST)

On Wed, 27 Nov 2002, Choi, Don wrote:
    > not based on military standards.
    > We (DISA) think that IETF is the place to develop these standards.

Do you really not see the contradiction here?  "We want to buy an
off-the-shelf solution that has shared fate with what other people want.
Therefore you must redesign your product to meet our exact
specifications and convince everyone else to buy something other than
what they want?"

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Nov 2002 09:42:40 -0500

On Wednesday, Nov 27, 2002, at 11:37 America/Montreal, Choi, Don wrote:
> pre-empted nor packets should be dropped.

	It is very helpful to get the objective outlined and on the table.
Thanks much for that.

	I had thought MLPP meant "Multi-Level Precedence & Pre-emption",
but that must be a misunderstanding since you seem to say above that
"pre-emption" is not part of the requirement.  Please help me understand
whether pre-emption (e.g. dropping other packets at the IP-layer,
dropping other calls inside a SIP server) is a requirement.

	I assume "calls" means "telephony applications running over IP";
if that isn't your meaning, please clarify.

	Is that for "calls" on DoD IP networks (e.g. NIPRnet, SIPRnet, base 
LANs,
service-specific or agency-specific networks), on commercial networks 
where no
DoD contract is present, for DoD networks operated by a contractor 
(e.g. DREN),
or for some other scope of networks ?

	Also, is the scope limited to VoIP applications ?  Or does it include 
all
IP-based applications ?

	I ask because according to some folks working on DISN, the scope of 
DISA objectives
is *broader* than just MLPP handling for voice calls, but instead 
includes application
of MLPP at the packet level (IP layer) to a broader array of 
applications that
might run over IP.  This causes me some confusion.

	Is your objective the same as the DISN folks' objective ?  Or are 
their multiple
objectives in different parts of DISA ?  Is the NCS objective for the 
commercial
world identical to the DISA objective for DoD IP networks ?

	Aside:  The big challenge with the objective you have outlined at the 
top is that
"The Internet" is *unaware of* voice calls.  "The Internet" as 
available from
commercial ISPs [1] deals in IP packets *only*.  Similarly, the current 
DISN
deployment mostly (no doubt some exceptions exist) deals just in IP 
packet transport
from an access router (e.g. at a base) across the WAN to another access 
router
(e.g. at a different base).

	Now there are some methods already outlined on this list, which mostly 
do not use
any IETF standard and do not require any new IETF standards, that can 
generally achieve
the objective you outline at the top.  Here is an example:

	- overprovision the backbone, but do not bother with QoS there (no 
standard needed)
	- enable router-based queuing on access routers (e.g. Sprint's CoS 
service)
		(router-based queuing is not subject to IETF standards; many vendors 
support it)
	- either overprovision the site LAN and/or deploy QoS within the
		single site (e.g. building, base, ship, plane).  (no standard needed)
		- Within a single site, enterprise users often deploy IEEE 802.1p
		  precedence inside an Ethernet LAN/MAN (IEEE standard exists; no 
IETF std relevant)
		and DiffServ/IP-ToS (IETF std exists already), combined with 
vendor-specific
		filter rules to apply/remove/modify QoS and QoS markings (router 
filters
		aren't subject to IETF standardisation, except maybe in a MIB spec; 
most
		vendors already support this).

> combined interoperability with our allies and partnership countries.

	It seems to me (and some others here who have agreed with the general
concept) that the solution approach I outlined just above will work for
the objective at the top.

	If I'm missing something, which I guess is likely, then please help me
understand what more you are seeking.  (I'm mostly an IP-layer and 
routing
kind of person these days, so I'm likely missing stuff up inside SIP or
elsewhere in the application layer because of my own ignorance.)

Ran
[email-masked]

[1] ISPs are somewhat different from content providers.  The latter 
group
would include (by my own definition) folks such as MSN or AOL, each of 
whom
reportedly [2] outsources much of its WAN IP/dialup services to one or 
another
ISP.

[2] According to The Washington Post.