Subject: RE: [Ieprep] access and enterprise networks

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 1 Apr 2003 13:51:00 -0500

Stu,

>There is also another method for solving particular congestion 
>problems (at
>least for some cars).  One can put in a special lane (say for 
>high occupancy
>cars) on that highway.
>
>I was surprised that you did not also address those few 
>selected vehicles
>with flashing lights and a siren that can get "Platinum Service" on the
>existing roads without the need for new lanes.

Not sure how to answer.  I was speaking figuratively to get the ideas
across.

One idea...if the road in question is a loaded link, then all packets
already on that link have to move in order.  I can't tell packets to pull
over into the curb of a link because there is a packet with a siren and
flashing lights behind it.  We have no space to pull over. 

Another idea...if the analogy is the entrance onto the highway, then this
"platinum service" is basically what I have described as gold.  There is a
preference to which cars get entry.  This is invariant of whether you use
the preference for a particular ingress link connected to an ETS location,
whether the packets are labeled using DiffServ, or whether the packets are
associated with a particular RSVP reservation.  It's all basically
scheduling at any one hop.

Perhaps this clarifies.

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

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 1 Apr 2003 14:47:52 -0500

Actually, I think the siren analogy is quite good.  When emergency
traffic does have to get thru,
(most rational) people  don't mind making way for that emergency
traffic even if they are slightly delayed.
One factor is that such emergency traffic  (let's not call it
e-traffic) is less than 1% of the total. Thus, overall,
the impact on normal users is acceptable.
Such prioritization is possible at the packet network.  The
Multi-Level Expedited Forwarding PHB has been built and successfully
tested.
An I-D <draft-silverman-diffserv-mlefphb-00.txt> was submitted on this
subject just before the SF meeting but then the Diffserv WG was
closed.
This does not address signalling or authorization but I view these as
solvable problems.  The PHB does demonstrate that multiple levels of
priority can work in a packet network.

Now the question is: Do we need "Emergency Vehicles" on a  global
voice network?  People with some backgrounds answer  "Of course",
while others respond negatively.  (Perhaps they also refuse to pull
over when overtaken by an ambulance.)
The analogy shouldn't be pushed too hard but the function is necessary
to the DOD and some other possible customers have indicated interest.

Steve Silverman
Houston Associates

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> King, Kimberly S.
> Sent: Tuesday, April 01, 2003 1:51 PM
> To: 'Stuart (Stu) Goldman'; King Kimberly S.; 'Nguyen An'
> Cc: Ieprep (E-mail)
> Subject: RE: [Ieprep] access and enterprise networks
>
>
> Stu,
>

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Apr 2003 15:17:14 -0500

On Tuesday, Apr 1, 2003, at 14:47 America/Montreal, Steve Silverman 
> traffic even if they are slightly delayed.

An issue is that buffering in access/enterprise CPE routers/switches
is generally pretty shallow (because folks who buy such products
do not want to buy RTT ms of buffer).

So in the places likely to have congestion, lack of buffering
might be a significant practical issue for the deployed equipment.

Which is to say, the choice is not "slightly delayed" versus "not 
delayed"
but instead is "dropped" versus "forwarded" -- to use the increasingly
strained traffic analogy.

> the impact on normal users is acceptable.

Maybe.  The 1% number comes from GETS statistics, right ?
Not from any real IP-based service, right ?

If someone actually has specific measured IP packet utilisation
for an IP-based preference system, that would be interesting
to hear about and a lot more relevant to the discussions here.

> Multi-Level Expedited Forwarding PHB has been built and successfully

A significant problem is detecting forged packets or forged IP ToS bits
on packets.  Absent such ability to detect bogon packets, deployment
of end-to-end DiffServ (with any DiffServ PHB) creates a 
trivially-exploited
DoS/DDoS attack on the infrastructure.  Within a single policy domain,
ACLs or other filtering *might* be able to reduce that risk to 
acceptable
levels.  However, no one has described any mechanism for reducing that
risk to acceptable levels in an inter-domain context.

> solvable problems.

It would be interesting to see your specific proposals on those issues
(and on authentication, without which authorisation could be subverted).

Are there any I-Ds on those ?

> The PHB does demonstrate that multiple levels of

We already knew that from the old (80s) DDN, which deployed the RFC-791
8-level DoD precedence system in the production DDN of that time.

> voice network?

I don't think so.  I think the first questions are can any such system
be deployed in any reasonable way.  So far, the answer is that such a
system could only reasonably be deployed within a single policy domain.

Absent specific credible technical proposals that solve the 
inter-domain issues,
it is greatly premature to raise the question quoted above, IMHO.

Ran

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 1 Apr 2003 17:12:36 -0500

> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2003 3:17 PM
> To: Steve Silverman
> Cc: Ieprep
> Subject: Re: [Ieprep] access and enterprise networks
>
>
>

Yes, some packets will be dropped.  Voice packets that are delayed
more than
a jitter buffer's worth are worthless.  But these should be a small
percentage of any
one user's packets.  see below.

>
> > One factor is that such emergency traffic
> >  is less than 1% of the total. Thus, overall,

> Not from any real IP-based service, right ?

The number of users in each DOD priority class is less than 10% of the
class below it.
I do not believe that anybody has run tests on this but my guess is
that  very few users would notice
much degradation of voice quality.

> on packets.

Granted.  I have been working on DISA to fund work in this area for
some time.

> Are there any I-Ds on those ?

They haven't funded me to do this yet. This is a big area. I would
expect a number of people/companies to be
involved in this once they decide to do it. They can't deploy VoIP
without it.

> I don't think so.
You are certainly entitled to your opinion but the JCS has stated
that MLPP must be supported and VoIP can't be deployed without it.
This is only one private net but in the past, it has set a standard
for
various other nets and the DOD tries to run multi-vendor networks so
they prefer
standards done in a public forum. That's why this is being discussed
here.

I think the first questions are can any
> such system

Actually, the DOD is primarily interested in one policy domain, their
private network.
But I think that if VoIP is ever to be supported by real carriers as a
public net, the
architectural model and certain security aspects will change
signficantly from the current model.
The current SIP architecture is based on "smart terminal, dumb fast
network".  This is OK if you trust everyone but
history has shown that is a poor assumption.  I predict that before
Verizon or SBC is going to invest $Bs, they are
going to demand much better safeguards than are available now.  This
may ease the problems faced by the DOD since
all major carriers have some of the same concerns.

Steve Silverman

> it is greatly premature to raise the question quoted above, IMHO.

I think it is good to have an overview of where you are trying to
head.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Apr 2003 20:28:11 -0500

On Tuesday, Apr 1, 2003, at 17:12 America/Montreal, Steve Silverman 
wrote:
> more than a jitter buffer's worth are worthless.  But these should be
> a small percentage of any one user's packets.  see below.

At least some of us think of IEprep as not being limited to voice
applications.  Certainly DISA folks (that I talk with about their 
interest
in precedence for IP networks) are saying that voice is not the main
application of concern for QoS.  Their main concerns seem to be with
TCP-based applications, such as mail/web/ftp/C3I stuff.

> class below it.  I do not believe that anybody has run tests on this
> but my guess is that very few users would notice much degradation of
> voice quality.

Are you saying that the statistics are for the AutoVON (DSN) system ?
Are you saying that this is what the (some part of US DoD) has as
a policy statement for their priority schema ?
Or are you saying something else ?

And when you say "degradation of voice quality", what is that
in reference to ?

>> A significant problem is detecting forged packets or forged
>> IP ToS bits on packets.
>
> Granted.  I have been working on DISA to fund work in this area
> for some time.

DARPA might be more likely to fund R&D on that.

>>> This does not address signalling or authorization but I
>>> view these as solvable problems.
>>
>> It would be interesting to see your specific proposals on
>> those issues (and on authentication, without which authorisation
>> could be subverted).
>>
> expect a number of people/companies to be involved in this once
> they decide to do it. They can't deploy VoIP without it.

I'll just say that it is not clear to me that these issues are
practical to solve in an inter-domain context.  Colour me sceptical
at least until a specific documented proposal appears that can be
openly evaluated.  :-)

> that MLPP must be supported and VoIP can't be deployed without it.

You misinterpret my comment.  I was saying that "I don't think that
is the actual question at hand", rather than trying to answer the
question either way.

One possible outcome from the JCS policy statement is that DISA/DoD
don't deploy VoIP.  Resolving the conflicts (if any) between their 
policy
choices and the technology they choose to deploy is their local matter,
rather than an IETF standards issue.

> for various other nets

It hasn't set a standard for non-government networks in at least 10
years.  In fact, at the moment, DISA (e.g. in GigBE) is directly trying
to change its modus operandi and instead of past practices, DISA is 
trying
to directly emulate "commercial best practices" in evolving its 
deployed IP
networks and services to be more effective than the current {N,S}IPRnet.

> and the DOD tries to run multi-vendor networks so they prefer

Lets not rathole, but I think DISA's MLPP problem is *solved* (and
am happy to explain why, in person if that's helpful) by DiffServ
-- in large part because DoD is a single policy domain, so the
inter-domain issues aren't particularly the ones facing DoD or DISA.

And I further think this is solved in existing IETF standards and
with product available from more than one vendor (though maybe not
available from all vendors).

> Actually, the DOD is primarily interested in one policy domain, their

See above.

> public net, the architectural model and certain security aspects will 
> change

A lot depends on what you mean by "real carriers".  At least 2 different
definitions come to mind:
	(A) real IP carriers
	(B) real telephony/voice carriers

Now group (A) is focused on moving IP packets around and tries VERY hard
not to look at more than the Destination IP address.  They have said 
repeatedly
on this list and in IEprep meetings that they do not plan to change
this focus anytime soon.

Group (B) might (hypothetically) move to a VoIP infrastructure, but 
appears
most likely to do so over an essentially closed, specially engineered,
IP network -- rather than over the networks operated by folks in (A)
-- at least for the forseeable future.

My own experience over the past several months, using the Bill Woodcock
phone system, is that his phone system works really well.  I share
Sally Floyd's concerns that the current technology underlying that
phone system lacks adequate congestion avoidance and control -- hence
might not be healthy for the global Internet, but that's a separate
issue from whether it works or not.

> network".  This is OK if you trust everyone but history has shown
> that is a poor assumption.

Au contraire.  History for the past ~20 years is that "smart host, dumb
fast network" is a VERY GOOD assumption for an IP network or for 
applications
on an IP network.  The history of voice telephony networks and of IP 
networks
is necessarily largely disjoint over the same time period.

Ran

---

From: Rex Buddenberg <[email-masked]>
Date: 02 Apr 2003 04:46:36 -0800

I'm a bit unclear on the objective.

Sigh ... qos/QoS discussions remind me of the observation about
economists: if you lined them all up end to end, they still couldn't
reach a conclusion.

Is the objective to have internet access for emergency services 
or is it
to have high quality of service (definition unclear) internet 
access ...(but on links that may not exist)?

Reiterate my plowshares-->swords checklist:
  - availability/survivability
  - security
  - qos
  - reach to mobile platforms
in my experience most requirements issues fall in these four bins so
makes a good checklist to see if you've got arms around the whole
problem.  From the thread of the last couple days, it looks like we've
got one of the four trees (qos) in the forest.  And, IMHO, not the most
important ones.  

Running through the checklist:
  - IP, by it's nature, is very amenable to high availability solutions
by provisioning backup comms so that outages can be routed around.  I
counsel my students to start here ... you may find yourself putting a
lot of the qos worries into the no-nevermind category.
  - the security component for emergency services that is most critical
is authenticity.  The technology is such that if you solve the
authenticity problem (and integrity is a subset solution), 
then you have all the pieces necessary for confidentiality as well.  
  - qos.  In the emergency services situations I dealt with in a former
life, I was generally happy when I had comms.  Whether it was 'high
quality' comms was never an issue.  Personally, I find the arguments
about QoS a bit tiresome and I can't shake the opinion that we're
chasing after a non-problem to the neglect of the real problems.
  - reach to mobile platforms is a big issue for emergency 
services just as it is for the military.  This category is also rife
with solutions (some of them pretty bad) chasing rather undefined
problems.  

Strikes me that using IEPREP to articulate the problem here would be
useful...

My observation of the traffic loading is that what used to be voice
applications tend to shift to some other flavor of data as they get
increasingly automated.  If engineered at all intelligently, this almost
always results in a more loosely coupled system meaning that there's
increasingly less need to fiddle with default qos behavior.  
	An example.  The dispatcher needs to know where the fire department's
engines are.  So she calls up on the radio and the engine driver
responds with his position (either by reading a street sign or by
reading the numbers off a radionav receiver).  Now overhaul the system
so the engine reports its position automagically ... without pestering
the driver.  We make the radionav receiver an end system on the network
and it periodically (or on poll, a la SNMP) reports its Lat/Long
coordinates which are poured into the dispatcher's database and
displayed on the GIS GUI.  At this stage of automation, the bursty
behavior of the internet is inconsequential.