Subject: Re: [Ieprep] problem context

From: [email-masked]
Date: Fri, 29 Nov 2002 13:09:18 EST

In a message dated 11/29/2002 9:48:06 AM Eastern Standard Time, 
[email-masked] writes:

On Wednesday, Nov 27, 2002, at 11:37 America/Montreal, Choi, Don wrote:
> 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.

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

[MAP] I believe the above is no different than what we have said multiple 
times in drafts and previous e-mails and meetings.

[RJA]    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.

[MAP] Dropping other calls inside a SIP server would be a requirement if 
there were no other way to achieve the general requirement as Don stated it 
above. However, I truely believe that IP gives us better ways to do it than 
the call preemption that is employed in the circuit-switched world. But we 
haven't been able to get to a discussion of how it could do this, since we're 
stuck on an argument of whether any preferential treatment is required at all.

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

[MAP] We mean "calls" in the same sense as the word has meant for a long 
time, that is, a "telephone call between two end user". At the application 
layer, the meaning of this isn't changed by the use of IP to carry the bits.

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

[MAP]  As I believe has been identified, we need to consider equivalent 
preferential treatments for things other than "calls" (or VoIP application).

[RJA]    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).

[MAP] Yes, we're aware that the Internet is unaware of voice calls. That is 
why we have proposed that some form of "packet marking" will be needed to 
achieve the preferential treament goals. Isn't that exactly what AF and EF 
did?

[RJA]    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).

[MAP] As I believe we have made clear, overprovisioning is not an acceptable 
solution for the emergency/disaster situations that we are addressing. Could 
we eliminate that from any further discussion? Of course, router-based 
queuing on access routers is a part of the answer. Yes, within a LAN, there 
are other solutions.

But the bottom line, after all the existing solutions are laid on the table, 
is that none have been able to explain how priority calls get the required 
treatment over regular calls on IP-based networks in a situation of 
congestion using existing standards.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Nov 2002 18:27:23 -0500

On Friday, Nov 29, 2002, at 13:09 America/Montreal, [email-masked] 
wrote:
> [MAP] Yes, we're aware that the Internet is unaware of voice calls. 
> That is why we have proposed that some form of "packet marking" will 
> be needed to achieve the preferential treament goals. Isn't that 
> exactly what AF and EF did?

	Neither AF nor EF is widely deployed.  Each has some deployment.  I 
know of
two EF deployments in large WAN networks (a US academic/research 
network and
a European academic/research network).  The AF deployments that I'm 
aware of
are all inside single-domain private networks (e.g. corporate 
LAN/MAN/WAN
situations).  DiffServ appears to not be practical to deploy for 
eng/ops reasons
in an inter-domain situation where at least one domain is a commercial 
ISP.

	DiffServ/802.1p are widely implemented in switches/routers.  
Implementation
quality varies widely today.  Most of the deployments seem to be inside 
a single
administrative domain inside an "enterprise" private network.  Most of 
the issues
identified here and elsewhere relate to inter-domain DiffServ (e.g. 
where ISP A hands
marked packets to ISP B and someone expects ISPs A and B to do 
non-best-effort things
based on the packet markings).  For operational security reasons, ISPs 
often clear the
IP ToS byte in current deployments (which might impair our ability to 
deploy ECN, btw).

	So if DoD wants to use DiffServ *inside* DoD, I think that is 
practical (and
think I've said so in the past).  It is the deployment of inter-domain 
QoS
(of any sort, including DiffServ) that seems intractible right now.  
One of
the IAB documents (RFC-2990 ??) talks about this as well.

> [RJA]    Now there are some methods already outlined on this list, 
> which mostly do not use
>        (router-based queuing is not subject to IETF standards; many 
> vendors support it)
>        precedence inside an Ethernet LAN/MAN (IEEE standard exists; no 
> IETF std relevant)
>        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
> [MAP] As I believe we have made clear, overprovisioning is not an 
> acceptable solution for the emergency/disaster situations that we are 
> addressing. Could we eliminate that from any further discussion?

	We can't eliminate that until the folks who want to eliminate that can
deliver a persuasive argument that it can't work (and explaining why
the past scenarios where it DID work aren't applicable is probably
a part of that).

	So far, I keep hearing NCS/DISA-funded folks say that 
"overprovisioning is not
acceptable" but I haven't heard any technical reasons why that is the 
case.
To my ears, it just sounds like policy rather than engineering.

	(And to be fair, apparently the operators' several claims that 
overprovisioning
has worked fine so far in various emergencies isn't persuading the 
NCS/DISA-funded
folks here either).

> Of course, router-based queuing on access routers is a part of the 
> answer. Yes, within a LAN, there are other solutions.
>
> But the bottom line, after all the existing solutions are laid on the 
> table, is that none have been able to explain how priority calls get 
> the required treatment over regular calls on IP-based networks in a 
> situation of congestion using existing standards.

	And I thought that was NOT Don's stated objective.  His objective was 
that the
preferredcalls were able to get through, which is one that the 
operators here seem
to think can be achieved (through some combination of over-provisioning 
and these other
mechanisms I discussed earlier).  Maybe I mis-read his objective ?

	The DoD tactical nets are a huge pain, due to lack of 
bandwidth/capacity,
but DoD operates all the equipment on those nets and so can deploy 
link-specific
solutions (e.g. router-queuing, link-layer QoS of whatever is 
available, others)
on those networks.  At least some of the services (e.g. Navy) were 
doing so in the
early/mid 90s on at least some of their tactical networks.[1]

Ran
[email-masked]

[1] It didn't hurt that they still have a lot of routers with John 
Moy's code,
	including TOS/QoS support that works well.

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

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 30 Nov 2002 06:34:52 -0800 (PST)

> stuck on an argument of whether any preferential treatment is required at all.

I think that many of us are trying to get you to address the question of
why you prefer preferential treatment to maximizing the liklihood of call
completion.  We look at what we think your high-level requirement is, "get
calls through," and then what you're saying "QoS, packet-marking,
call-awareness" and they appear to be diametrically opposed.  We like the
high-level goal, and can't see why you don't want to actually achieve it.

    >> "The Internet" is *unaware of* voice calls.
    > Yes, we're aware that the Internet is unaware of voice calls. That
    > is why we have proposed some form of "packet marking"

One of the things Ran has been trying to explain is that "packet marking"
doesn't make the Internet aware of phone calls.  These are orthoganal.
You can mark packets however you like, and it will not make them be
treated differently.  If it did, that would be a _really bad thing_.  You
_really don't want it to do that_.  The solution to getting calls through
is to buy the service you need, not to redesign the Internet to be
channel-switched.

    > As I believe we have made clear, overprovisioning is not an acceptable
    > solution for the emergency/disaster situations that we are addressing.

No, nobody has made that clear.  In fact, it's the only solution that's
actually worked.  Since it works, and the others don't, what is it that
you don't like about it?

    > congestion using existing standards.

Since nobody has demonstrated a need for that, no, nobody's engineered
that particular combination.  Since that combination appears to be
incongruous with your stated high-level goal, I think everyone who matters
is waiting for your (collective your) public statements to all come into
line before taking any action.

                                -Bill