Subject: RE: [Ieprep] problem context

From: "Choi, Don" <[email-masked]>
Date: Mon, 25 Nov 2002 12:52:36 -0500

Ran,

The requirement for MLPP like service in internet (IP-based network) has
been part of IEPREP WG all along. The requirement exists for emergency
situations, and it should work over an IP-based network. 

Don

Don
-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Friday, November 22, 2002 7:38 AM
To: King, Kimberly S.
Cc: [email-masked]'
Subject: Re: [Ieprep] problem context

On Thursday, Nov 21, 2002, at 18:40 America/Montreal, King, Kimberly S. 
wrote:
> The context of "Internet Preparedness" is vast.  Some of the most 
> heated
> debates involve people with one context in mind talking to someone 
> else with
> a different one.  So, they talk past each other.

This is without question the case.

> Below is a beginning that I invite the WG to refine.  The purpose is to
> facilitate problem solving.  One can state "here is the context and 
> here is
> a problem where the default situation is insufficient to solve 
> emergency
> service X".
>
> 1.	N ETS locations with access links into the same ISP where the ISP
> offers CoS. Note that the particular ISP, access link bandwidth, and 
> local
> configurations can be determined in advance of the emergency.
>
> 2.	Emergency Worker accesses Internet via arbitrary connection (e.g.,
> Internet Cafe).  Note that the ISP providing connectivity to the 
> Internet
> cannot be determined in advance.
>
> 3.	A predetermined network is connected to a privately managed IP WAN
> over a predetermined constrained bandwidth connection (e.g., military 
> ship
> to Government owned IP network over Satellite)

This (3) is not an IEprep scenario.  It is a real-world military 
scenario,
just not an IEprep scenario.  And IEprep is NOT the MLPP WG.

(Aside: A suggestion I have made to the IESG is that they create a 
DiffServ Ops
WG that would be a home for evaluation/documentation of how the current
DiffServ protocol specs line up in practice with real-world operational 
networks.
Based on the output of that hypothetical WG, one could imagine that 
DiffServ specs
might be enhanced/tweaked/fixed based on real-world experience.  
DiffServ is
the obvious mechanism for item (3) above since it was used, albeit 
under another name,
some years back by US DoD to provide that capability [using Proteon 
routers if
memory serves].)

> 4.	A database available on the public Internet supporting emergency
> services/recovery (e.g., Japan's IAA)
>
> 5.	James Polk's topology scenarios
>
>
> While each case potentially involves some form of emergency 
> communications,

Item (3) describes military communications rather than emergency 
communications.
Military communications might (and do) have varying degrees of urgency
and precedence, but they aren't emergency communications.  Examples of
emergency communications would be from civilian organisations such as
Fire, Police, or FEMA.  Military networks might happen to carry some
messages related to a natural disaster, but that does not make such 
networks
IEprep networks.

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: Sean Donelan <[email-masked]>
Date: Mon, 25 Nov 2002 13:15:37 -0500 (EST)

> situations, and it should work over an IP-based network.

At the BOF forming this working group, I thought MLPP was decided to be
out of scope of this working group.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Nov 2002 13:18:11 -0500

On Monday, Nov 25, 2002, at 12:52 America/Montreal, Choi, Don wrote:
> been part of IEPREP WG all along.

	Disagree.  It has NOT been here "all along".   It is an example
of "feature creep" or "charter creep".  I've been at each IEprep BOF
or WG meeting.  MLPP hasn't even been discussed at most of them.

	Also work specifying an MLPP mechanism is outside charter, since IEprep
does not do protocol design.

> The requirement exists for emergency

	No.  That is also wrong. The requirement for emergency situations is 
that
the packets actually get delivered, NOT that anyone have, implement, or 
deploy
MLPP (or any other particular mechanism).

	The WG to address MLPP is probably DiffServ.  I infer that DoD/NCS 
folks haven't
succeeded (yet ?) in persuading DiffServ to specify something that 
DoD/NCS folks like.
None the less, DiffServ is the WG where MLPP mechanisms are most likely 
actually
to get specified and where desires for MLPP need to get expressed 
(assuming folks
want MLPP to actually happen inside IETF specs).  Earlier it sounded 
like you all
grasped this fact and were trying to work within DiffServ; I must have 
misunderstood.

	Given absence of much (any ?) present/likely future deployment of 
inter-domain
DiffServ, it is actually a good thing that emergency communications 
over the Internet
does not need or rely on MLPP.

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Mon, 25 Nov 2002 16:31:40 -0500 (EST)

> situations, and it should work over an IP-based network. 

there are two cases here

1/ convey PSTN-service specific info from a SIP node on an IP network
   to a IP-to-PSTN gateway for its use in signaling within the PSTN 
   network - this would include binary-indicators like GETS and
   multi-level ones like MLPP 

2/ use something other than best-effort service within an IP network
   (for example, on the access links)

#1 is part of the SIPPING requirements ID that is in WG last call

the need for #2 has been the object of vigorous discussion on this list 
but I think that it is in-scope to look at specific requirements
and at how those requirements could be met with existing IETF technology

note that existing IETF QoS-related technology is not limited to
best-effort and one other service so I do not think that any
chnages would be needed in such technology to support a 5-level
service like MLPP if that turns out to be useful in an IP network

(I have my doubts that there is much meaning to more than two
or three different services (best effort and one or two others) 
considering the nature of packet data networks) but I doubt that any limit 
in levels would be dictated by the technology itself)

Scott

---

From: Scott Bradner <[email-masked]>
Date: Mon, 25 Nov 2002 16:36:42 -0500 (EST)

> The WG to address MLPP is probably DiffServ.

diffserv already can "support" MLPP if all that is wanted is 5 levels
of priority - as I just mentioned, I do not think that it makes much
sense to have 5 levels of priority in packet networks - I've not
seen any research that there is any useful differentation of services
as seen by the user

Scott

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Nov 2002 13:11:26 -0800

Hi,

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....

thanks,
-rohan

---

From: Scott Bradner <[email-masked]>
Date: Tue, 26 Nov 2002 16:25:05 -0500 (EST)

> context, possibly only in the context of audio media even....

I expect you are right

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 16:43:47 -0500

On Tuesday, Nov 26, 2002, at 16:25 America/Montreal, Scott Bradner 
>> context, possibly only in the context of audio media even....

	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