Subject: RE: [Ieprep] problem context

From: "Gunn, Janet" <[email-masked]>
Date: Tue, 26 Nov 2002 18:32:01 -0500

It seems to me that MLPP is a technical solution to solve a particular
problem in a (fixed) circuit switched network.

Just as eMLPP is a different technical solution to solve a similar problem
in a (mobile) circuit switched network.

I am not sure that it makes sense to REPLICATE either MLPP or eMLPP in an IP
network.

However, it may very well be useful to identify an (IP specific) technical
solution that solves the same basic problem.

And it would DEFINITELY be useful to identify ways of interoperating with
MLPP and eMLPP across the relevant gateways.

-----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: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 19:53:18 -0500

> MLPP and eMLPP across the relevant gateways.

There are at least 2 (maybe more) different layers that one can use to 
consider this
question:  application-layer (e.g. SIP servers) and IP-layer.  I am 
very unclear
which of these is meant.  Some folks use "gateway" to mean a SIP 
gateway,
some to mean another application-layer gateway, and some to mean an IP 
router.

If we look at this as an IP-layer issue, then DiffServ/IP-ToS is an 
approach that
can work *within a single administrative domain*.  The security issues 
(e.g.
DDOS attack using IP ToS bits) are primarily a problem on an 
inter-domain
boundary.  Within a single administrative domain, the authorities for 
that
domain can use domain-specific policies and mechanisms to mitigate their
operational risk.

If we look at this as a SIP issue, then it seems like the main concern 
might
be to ensure that whatever markings are associated with a telephone call
are preserved (or modified only as appropriate at an administrative
boundary -- example:  country X might by policy disregard/remove 
markings
originating on an international call from country Y).  Because of our
layered architecture, having a call marked with some bit pattern inside
SIP does NOT automatically imply any change from best-effort handling by
the IP-layer.  It would not prohibit it, but neither would it 
automatically
imply such.

I'm not quite sure which of these (or maybe some other items) is the 
focus
of the concern at NCS, and which of these is the focus of the concern at
DISA Centre for Standards.  It would help if those perspectives could 
be made
more clearly.