Subject: RE: [Ieprep] access and enterprise networks

From: "Nguyen, An" <[email-masked]>
Date: Tue, 1 Apr 2003 13:03:26 -0500

Kim,

-----Original Message-----
>From: King, Kimberly S. [mailto:[email-masked]]
>Sent: Tuesday, April 01, 2003 12:36 PM
>To: 'Nguyen, An'; 'King, Kimberly S.'
>Cc: Ieprep (E-mail)
>Subject: RE: [Ieprep] access and enterprise networks

>I don't totally agree with the notion that locations of any 
>emergency can be

>Helping performance in IP networks may take a rethinking of what it takes
to
>be successful.  At a minimum, it may require redefining what it means to be
>"taken care of first" and the definition of when there is "congestion".  IP
>network performance is inherently statistical rather than an ordered
>deterministic "this call first, then that one". 

What I meant here is in more or less in high probability of call completion,
not a deterministic sense. 

>For networks with best effort service (e.g., the overwhelming majority of
>ISPs), it might make sense to have the provider guarantee some minimum
>throughput for particular locations.   Let's take an example of driving a
>car in my town.  Vehicular traffic in Washington D.C. can be congested.
>One method to control congestion on a highway is to control the rate
traffic
>enters the highway.  One method of gold service says ETS locations get to
>put more traffic on that highway when the on-ramps are busy.  

Are you suggesting that some sort of call admission control mechanisms to
make sure that, for the lack of better words, traffic other than best effort
has some sort of treatment?

>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.  This is more a RSVP/DiffServ approach and may be
>appropriate on certain enterprise networks.

I could not agree more with you on DiffServ.:-)

An

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

---

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

An,

>has some sort of treatment?

Maybe.  Depends on how you define "call admission control" and "some sort of
treatment".  I'm not thinking about calls but rather just packets.  Back to
my vehicle traffic control analogy.  Suppose some highway on-ramp can
support 10 cars gaining entry to the highway every 5 minutes.  I'm
suggesting a minimum of those cars are ETS ones (say 4 out of 10).  In
network terms, suppose a (bottleneck) link can support a certain rate per
second of traffic moving through.  Suppose, for example, we guarantee 40% of
those packets that get through are ETS. It's a preferential treatment to get
on the highway.  Once on the highway, all cars drive best effort.

Picture time...
(use fixed-width font such as Courier).

Imagine 3 locations, two "regular" and one ETS share a connection to the
network.  This link can get congested.  Suppose regular locations are moving
traffic at about 50% of that link speed while ETS is sending traffic at
about 45% of the link speed.  Normally, (assuming we can load to 100%), we
should see 45% of the traffic drop and it might all be assumed to be roughly
distributed among the locations.  What I'm suggesting is a way for ETS
traffic to have preferential access.  If the guaranteed minimum were 40% for
ETS, then only 5% of that ETS traffic would be dropped.

   --
     -- Regular 50% link speed                    ---
       ---                                    //--   --\\
 ---      ---                                /           \
    -----    --    bottleneck link          /             \
         ----- --                          |   Network     |
   Regular    ---  ------------------------+        |
   50% link speed|                         |               |
           ---   |                         |               |
       ----      |                          \             /
    ---          | dropped                   \           /
  --             |                            \\--   --//
   ETS 45%       |                                ---
               \ | /
                \|/
                 \

                traffic dropped 45%,
                40% regular traffic
                5% ETS

Note, I don't want to write the draft real-time on the list but I'm trying
to provide what I think are some valid (and cost effective) ways to use the
natural methods of IP networks to achieve the desired result.

I hope this provides a good direction for a best-effort network.

Kimberly

---

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 1 Apr 2003 14:41:59 -0500

An,

>Interesting idea! Why would I buy 10 cars knowing that I can 
>only use 4 when
>I need to use them. 

I don't think we are communicating.  If getting 40% of the shared bandwidth
from a public serving ISP isn't good enough (or some reasonable percent)
then you need to consider a priviate network.  As was discussed at the last
meeting, it is highly improbable that an ISP will give ETS 100% of the
bandwidth, even if they ask.  This sharing idea is consistent with Wireless
Priority Service.  If you can find an ISP willing to offer you 100%
bandwidth and they feel their other customers will accept such service
during emergencies then fine.  Some pointed out that everyday folks made
important 911 calls during September 11th.  I have no axe to grind, I'm just
repeating points made by others at previous ieprep meetings and on the
lists.

An said:
>Interesting concept! How would you distinguish ETS and non-ETS 
>traffic from
>a routing perspective?

The type of classification I described can be done many ways.  One simple
way is to imagine a router who connects to three customers. The router can
keep track of what packets came in on what link.  This is an easy technical
problem and Ran mentioned some techniques earlier.  The point shouldn't be
the mechanism here, the point should be is this service acceptable and if
not then can you provide a concrete alternative?

Kimberly

---

From: "Beard, Cory" <[email-masked]>
Date: Wed, 2 Apr 2003 15:41:39 -0600

> 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)?

I very much agree.

There is a very real possibility of seeking to provide _unnecessarily good service_ to emergency users.  I have not heard it said that emergency users, for example, require better quality audio.  There is no reason for an emergency packet to move to the head of the queue when it arrives at a router.  It just should not be as likely to be dropped or experience unacceptably high delay.

Our belief is that the solution lies with an authentication/marking mechanism coupled with emergency-oriented active queue management that during congestion drops packets in a preferential manner.  

This would only be done at choke points, not along the whole path.  These choke points would likely be at the uplinks to ISP's, regional networks (like the network here in Missouri that connects all the schools in the state together), and in resource-constrained access links (wireless, residential cable networks, etc.)

Some of this is discussed in the Framework draft in Section 4.1.3.  Any comments about what is written there?

Cory Beard

---

From: [email-masked]
Date: Wed, 2 Apr 2003 23:04:56 EST

In a message dated 4/2/2003 4:44:51 PM Eastern Standard Time, [email-masked] 
writes:

> There is a very real possibility of seeking to provide _unnecessarily good 
> service_ to emergency users.  I have not heard it said that emergency 
> users, for example, require better quality audio.  There is no reason for 
> an emergency packet to move to the head of the queue when it arrives at a 
> router.  It just should not be as likely to be dropped or experience 
> unacceptably high delay.
> 

This is exactly the point of the MLEF that Steve Silverman referred to and 
explained in a draft. "Emergency" packets are not queued ahead of others. 
Thay have lower drop probability.

Mike

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Thu, 3 Apr 2003 05:17:50 -0600

>  Thay have lower drop probability. 

ok. But, my question is more general. who are we to suggest a policy configuration? 
Depending on the contract, ISP provide a suitable service to an emergency responder 
(i.e. if you pay more, you get a better service.) I forsee different scenarios: 
situations where the high-priority class is the "best-available" service or just 
that ieprep works fine with the best-effort. So, I see no reason in discussing a 
policy issue (i.e. "emergency" packets are not queued ahead of others) 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Patrick M Killian" <[email-masked]>
Date: Thu, 3 Apr 2003 19:52:06 -0500

We are doing quite a bit government VoIP private network (pt to pt )wan
deployments with G729 - non secure and ADPCM G726 secure over satellite and
radio.

---

From: "Gunn, Janet" <[email-masked]>
Date: Tue, 29 Apr 2003 15:46:50 -0400

*Sorry to be so late getting in on this.

*Comments in line

-----Original Message-----
From: King, Kimberly S. [mailto:[email-masked]]
Sent: Monday, March 31, 2003 11:57 AM
To: Ieprep (E-mail)
Subject: [Ieprep] access and enterprise networks

At the last meeting, people expressed an interest in addressing access and
enterprise networks.  As frustrating as it might seem, if there is to be any
progress, the problem still has to be precisely defined.  

Let's consider defining the problem and it would be nice to factor in some
practical realities too.  

Here are some assumptions: 

A) ETS locations are known in advance of any emergency. When an emergency
occurs, each will already be connected to a network (unless the emergency
damaged the connection in which case that situation is out of scope).

* There are several variations on this.  While some kind of service which is
available 
*everywhere (based on some sort of authentication) would be "nice to have",
it is obviously
* impractical.  So specifying in advance the "ETS location" is an acceptable
compromise.
* But there are a couple of additional considerations.

* First, we don't necessarily want ALL traffic from the ETS location to get
"special" 
* treatment, ALL the time.  We want to be able to identify specific 
* connections/sessions/applications/packets for "special treatment" at a
specific time.  
* This is one of the considerations that keeps the total volume of "special
traffic" down.

* If the biggest bottleneck is on the connection from "Site A" to its ISP,
then giving 
* "special treatment" to ALL traffic from Site A would be counterproductive.

* If EVERYTHING is special, then NOTHING is special. 

* Second, the predefined set of "source sites" might be quite different from
the
* (predefined or not-predefined) set of "destination sites", where
source-destination makes
* sense at some levels (e.g. application) but might not at others (e.g.,
packet).

*Third, it would be nice if the definition of "predefined site" included
some provisions 
*for mobility (dial up, wireless, etc.), within the constraints of a
predefined ISP 
*relationship.

B) Generally, we aren't trying to simultaneously solve the problem for every
ETS location in the entire world at the same time.  Rather, subsets of ETS
locations are affiliated with each other and some policy decision (and
likely funding scenario) is made for that subset.  An example, say all fire
stations in particular county want to procure IP connections for their use.
Meanwhile, a city's hospitals might be under completely different policy and
funding and aren't particularly interested in paying for enhanced
communications via some fancy IP network with the fire stations.  

* If you can completely define the community of interest (e.g., all the fire
stations) 
* then a VPN of some sort is the obvious solution, and within a VPN all
sorts of 
* special treatment is possible.

* While restricting it to such a small community of interest makes the
solution easier, 
* it is not as valuable as a solution that involves SOME sort of special
treatment 
* between the communities.  For instance, in your example, I can easily see
situations
* where the fire department would want to get high priority information to a
hospital (and the hospital would want to receive that information).

So, what is it that we want to ensure?  Would ieprep like a service that
provided some minimum bandwidth guarantee (like gold service) over the
access link and that's sufficient to make everyone reasonably happy?  If
that kind of service just isn't acceptable, then please provide some text
and details about the problem you believe we need to address.

* I think a "minimum bandwidth guarantee" is probably sufficient, 
* but it may no be necessary. 
* There may be other ways of providing preferential service that are related
to the 
* offered load, and the proportion of the offered load that is "special",
rather than 
* an a priori guarantee.

* Janet

Kimberly

---

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 30 Apr 2003 08:08:03 -0400

>* If EVERYTHING is special, then NOTHING is special. 

I understand your idea however I was addressing a different scenario.  The
idea is that the bottleneck is often an aggregation point from multiple
customers into the main ISP network and that Site A (ETS) would have greater
throughput at that aggregation point.

See 
http://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg01911.htm
l
for a picture.

Kimberly