Subject: RE: [Ieprep] Internet faults, VoIP demo, etc and others

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 2 Dec 2002 12:56:10 -0500

OK.
For these "concrete solutions to access link congestion issues", how do you
suggest we identify "emergency" traffic?

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, December 02, 2002 11:17 AM
To: [email-masked]
Cc: ieprep
Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

Please STOP claiming that concrete solutions to the access link 
congestion
issue have not been offered.  It is a bold-faced lie and it is quite 
tiresome
at this point.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 15:00:20 -0500

> suggest we identify "emergency" traffic?

	For traffic originating on a site behind that congested access link, 
one
could configure such a local policy into the access routers (a la 
Sprint's
example web page).  There are a very wide range of policies that could 
be
configured into the routers.  For voice traffic, one could prioritise 
voice
based on combinations of (protocol/port number/IP address) if desired.  
For
traffic originating inside a given domain, access lists and other COTS 
methods
can be used to prevent unauthorised access from within that domain.  
ToS bits
can be used within a domain and on the access link between that domain 
and its
uplink ISP.  Using ToS bits in the IP header or Ethernet header is 
pretty common
for intra-domain QoS deployments existing today.

Ran