Subject: RE: [Ieprep] identification of packets

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 5 Dec 2002 10:24:15 -0500

The higher the layer the better, I think.

Hypothetical example (sticking to VoIP as the example, but I don't want to
restrict the discussion to JUST VoIP):

Caller is at a site A, served by SPRINT, with their congestion control
mechanism implemented on the access link.

Celled party is at site B served by Genuity, with their congestion control
mechanism implemented on the access link.

Assume that both site A and Site B have configured their access lines so
that there is  category of traffic which is called (by people, not
necessarily machines) "emergency"?

Assume, for the time being, that the sites are owned by "FEMA" and the "Red
Cross", so that you know in advance that there is likely to be emergency
traffic between them during an "incident", and any business arrangements are
worked out in advance. (I am also interested in the "opportunistic" case
where there is not a business arrangement in advance (e.g., Internet Cafe),
but that seems much harder, and much more open to DoS abuse.)

Then the question is: "Is there a way for site A to mark "the traffic" (at
whatever layer is most likely to work) so that it recognized as "emergency
traffic" on both access links?  And for the traffic to be given the Sprint
"emergency treatment" at site A's access link and Genuity's "emergency
treatment" at site B, which might actually be different treatments?"

If it is possible, is it practical, and what are the drawbacks, and to whom?

I am asking nothing from the ISP core, except to pass the "marking" (so ToS
bits won't work).  

-----Original Message-----
From: Bill Woodcock [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 8:11 AM
To: Gunn, Janet
Cc: 'RJ Atkinson'; ieprep
Subject: RE: [Ieprep] identification of packets

      On Mon, 2 Dec 2002, Gunn, Janet wrote:
    > Is there a consistent way to identify emergency traffic across several
    > different "entities that are addressing congestion on the access
links"?

At what layer?  The lower the layer, the more expensive doing so would be,
and the more difficult it would be to avoid spoofing or misuse.

    > And, is there a way to pass that "identification as emergency traffic"
from
    > the access links at the originating node to the access links at the
    > terminating node (if the terminating node is in another domain)? (From
what
    > I have read here, and ToS bits based marking would be lost in the
    > intervening ISP.)

Excuse the BUAG.  Topology looks like this:

 Cust A                  |     ISP A    |     ISP B     |          Cust B

 LAN--CPE rtr--tail ckt--acc rtr--core--ix--core--acc rtr--tail--CPE--LAN

The phones and SIP devices are all on those LANs.  The CPE routers aren't
capable of manipulating anything or doing any QoS or anything like that.
The tail circuits are the portion where there's economic incentive to
congest them occasionally.  The portion between the access routers is the
part under the ISPs control, collectively, but it doesn't experience
congestion, and can't afford the high failure rate associated with QoS,
even if QoS had some beneficial effect.

So effectively, what you've got to play with is the stuff going onto the
LANs.  But fortunately, that's where you get your big win, since that's
what does all the call setup, origination, answering, redirection, et
cetera.

                                -Bill

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Dec 2002 09:24:22 -0500

> restrict the discussion to JUST VoIP):

... (and thanks for being so detailed with the example, I think having
a specific example to focus on will in turn help focus discussion)...

> traffic" on both access links?

	Inside SIP, subject to stuff in draft-carlberg-ets-telephony-*.txt
and Henning's draft getting added (if not already there in SIP),
then clearly it ought to be possible to mark things from a SIP
application-layer perspective.  So this will help both for VoIP
stuff and in pass-through (PSTN--VoIP--PSTN) cases.  Marking inside
SIP does NOT imply anything about what happens at a layer below SIP,
however.

> And for the traffic to be given the Sprint "emergency treatment" at 
> site A's
> access link and Genuity's "emergency treatment" at site B, which might 
> actually
> be different treatments?"

	Yes.  And each router would need to be specifically configured.

This configuration might look like a filter (source = FEMA VoIP subnets,
destination = RedCross VoIP subnets, protocol = UDP, and port = {member 
of
the particular port range used by VoIP} combined with some specialised 
queuing
treatment (e.g. Weighted Fair Queuing, with preferred weight for the
special VoIP traffic).

If one makes the further assumption that each site is using modern 
IP/Ethernet
equipment internal to the site, one might want to create DiffServ ToS 
and/or
802.1p ToS markings on the last acccess router in the path -- so that 
the deployed
Ethernet and IP infrastructure within the site might be able to use 
those labels
(intra-domain) for preferential queuing in routers and switches.

Also, if that further assumption is made, then one choice would be to 
config
the originating IP Telephone device to mark its outbound packets with 
some
DiffServ/IP ToS and 802.1p ToS markings so that the originating site 
might
be able to use those labels (intra-domain) for preferential queuing in 
routers
and switches.

> If it is possible, is it practical, and what are the drawbacks, and to 

I think it is practical.
Drawbacks are:
	- need to add the special configurations to the applicable 
routers/switches:
		- minimum in the site's access routers
		- preferably also in the ISP's access router on the other side of the
			access link
		- preferably also in the switches and routers within each site
	- increased complexity of the router configurations
	- need to deploy source address filtering throughout the FEMA site
	  and the RedCross site to prevent source address spoofing
	  (IMHO, not a big deal since that is commercial best practice anyway
	  as a more general security measure for any end site) [1]
	- need to have equipment with the right feature set (or spend money
		to purchase/deploy equipment with the right feature set).
	- probably need to pay the ISP to perform the needed config on its
		access router on its side of the access link (depending on ISP,
		this might or might not be a service offered)
	- might need to change ISPs from an ISP that won't enable special
		queuing (on its access router on its side of the access link)
		to an ISP that will do it (presumably for an extra fee).
	- depending on the knowledge level of existing IT/LAN staff at each
		site, might need to either provide more training or hire a
		consultant to help figure out the desired configs for all the
		equipment.
	- more complicated configs are harder to debug if a problem arises
	- more complicated configs are harder to replicate if equipment
		fails and/or is otherwise replaced by other equipment
	- the intra-site network design/deployment is more complicated.

This increased complexity translates into several high-level issues:
	- probably a longer MTTR for the system overall
	- probably a shorter MTBF for the system overall
	- possibly increased capital costs at each site
		(depends on whether existing equipment has the right features already)
	- probably increased ISP uplink costs
	- certainly increased operational costs for IT staff
		(either more training for existing staff, more expensive staff,
			or hiring outside consultants)

I hope this helps.

Ran
[email-masked]

[1] For reasons I described in detail in an earlier note, it is not 
practical
for an ISP to deploy source-address-spoofing filters on links to most 
other
ISPs (i.e. inter-domain situation).

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 17:59:00 -0800

Hi Janet,

Your scenario: FEMA wants to communicate with Red Cross is a useful 
one.  While a few folks have responded with QoS related solutions and 
VPNs, it is quite possible that the cost for FEMA and Red Cross to each 
get several (diverse) big pipes well connected to the core may cost 
much less than turning on QoS on smaller pipes.  I think these sites 
could certainly justify a couple of OC3s which is where the queuing 
delay starts to become negligible.

thanks,
-rohan

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 6 Dec 2002 21:35:57 -0800 (PST)

> I am asking nothing from the ISP core, except to pass the "marking" (so ToS

ISP B's access router would need to recognize and operate upon the
marking, as would ISP A's access router for the reply traffic, so they do
both have to understand it.  It's quite possible _using_ the ToS bits, but
for all the aforestated reasons, that's not practical, largely because it
would be abused.

If we know _in advance_ that the emergency traffic is going to be between
A and B, _or_ if we postulate somewhat smarter CPE routers than we have
today, then we can do this with static configuration in the access
routers and no new markings...  A's CPE router (or a separate
tunnel-endpoint termination device) policy-routes ToS-marked traffic into
tunnels, and both A and B just pay their ISPs a bit more for a service
which prioritizes traffic in established tunnels.  (As opposed to set-up
traffic, which could be spoofed to DoS an endpoint.)

                                -Bill