Subject: RE: [Ieprep] identification of packets

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 2 Dec 2002 16:37:20 -0500

OK,
Then take it a step further

Is there a consistent way to identify emergency traffic across several
different "entities that are addressing congestion on the access links"?
Does this have to be worked out on an entity-by-entity basis, or is there
the possibility of a "standard" (de facto or officially sanctioned) way of
marking such traffic?  If so that would take us a long way in the right
direction.  The appropriate treatment of the marked traffic would still have
to be negotiated on an entity-by-entity basis. 

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

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, December 02, 2002 3:09 PM
To: Gunn, Janet
Cc: ieprep
Subject: Re: [Ieprep] identification of packets

On Monday, Dec 2, 2002, at 12:49 America/Montreal, Gunn, Janet wrote:
> What is being asked is for IETF to help identify emergency traffic 
> WHEN SOME
> ENTITY is addressing congestion on the access links.

	Interesting.

	IP ToS bits can be used to identify preferred traffic inside a
domain
(and on that domain's access links to other sites or its ISPs).  
Enterprise users
often do that today (or use the 802.1p Ethernet precedence bits or 
other link-specific
methods for the same end).

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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 17:13:55 -0500

On Monday, Dec 2, 2002, at 16:37 America/Montreal, Gunn, Janet wrote:
> marking such traffic?

I think that it needs to be worked out on an entity-by-entity basis,
not because of lack of "standards", but because a lot of entities
aren't (today) willing to offer inter-domain QoS as a service at any 
price.
And in an IETF context, feature deployment is a local policy matter for
the network operator, not something that IETF would ever try to dictate.

If an entity doesn't offer inter-domain QoS as a service at all,
then it doesn't care how packets are labeled.

A digression.  There once was an ISP that offered a "Gold" service
to its customers in place of the "regular" service.  (I did not work
for this ISP.)  The implementation was reportedly as follows:
	1) Gold customers paid 50% more than regular customers for the
		same sized pipe.
	2) If a Gold customer felt during any billing period that they had
		not received good treatment, then they could call up the ISP
		and ask for a reduction down to the "regular" price for that
		billing period.

Most gold customers happily paid the extra money every month.  They
were happy because their packets did not get dropped.  The regular
customers were happy because their packets did not get dropped.  And
the ISP's shareholders were happy because the overall margins increased.

> I have read here, and ToS bits based marking would be lost in the

I don't know of any practical-to-deploy way to do that across arbitrary 
ISP
boundaries -- only because whether ToS bits are zeroed or not is 
properly a local
operator policy decision (and deployment policies are not within IETF's 
scope).
It is not a technical problem, just a contractual one (where the 
contract
would say bit pattern FOO is not zeroed by the ISP).  One might be able 
to work out
contracts with specific ISPs or some kind of multi-lateral contract to 
not zero
IP ToS bits, at least on particular links.   Any road, that necessarily 
would be
a business issue or a contractual issue, rather than a technical issue 
or standards
issue.

An important consideration is that during times of stress, more than a 
usual
amount of path change over time is likely (as the routing protocols 
route
traffic around any damage).  So if one wanted to have high probability 
of
ToS bit markings not being zeroed end-to-end, one would need to have 
contracts
with a whole lot of operators.

I think this takes us back to the perspective where the best approach 
would
be for NCS to contract with operators to deliver packets within some 
sort of
error bounds.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 5 Dec 2002 05:11:16 -0800 (PST)

> 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.

    > I have read here, and ToS bits based marking would be lost in the

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 5 Dec 2002 08:29:09 -0500

On Thursday, Dec 5, 2002, at 08:11 America/Montreal, Bill Woodcock 
> capable of manipulating anything or doing any QoS or anything like 

To be fair, Sprint and some other ISPs let some kinds of single-router
class-based queuing happen in CPE routers (and sometimes in a more 
limited way
also in Access Routers).  That queuing could be based on ToS bits of 
packets
from LAN to CPE or based on some combination of (address/protocol/port).
Good news, is that this sort of stuff will work on the link ("tail ckt")
that is most likely to be congested.

> congest them occasionally.  The portion between the access routers
  (i.e. acc-rtr -- core -- ix -- core -- acc-rtr)

> is the part under the ISPs control, collectively, but it doesn't 
> experience

Right.  That is the "inter-domain QoS" set of issues.

> what does all the call setup, origination, answering, redirection, et

Right.  Downside from a contractual perspective is that one generally 
will
need contracts with each end site if one wants that site's routers to 
have
a particular configuration deployed ==> lots of contracts to manage.

Ran
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 05 Dec 2002 08:37:49 -0500

> from LAN to CPE or based on some combination of (address/protocol/port).

Unfortunately, this COS arrangement is highly susceptible to 
denial-of-service attacks. For voice communications, there is no fixed 
source or destination address (even assuming you could do reliable 
address filtering), and in all likelihood, no fixed port. Thus, you'd 
have to assign this by TOS byte or protocol (say, UDP) only. Highly 
spoofable.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Dec 2002 08:57:37 -0500

On Thursday, Dec 5, 2002, at 08:37 America/Montreal, Henning 
Schulzrinne wrote:

> denial-of-service attacks.

All QoS mechanisms within the IP layer are highly susceptible to 
denial-of-service
attacks.  So I have no argument on your claim above.   Within a single 
administrative
domain, there is much more potential to manage/reduce risk from such 
attacks than
exists in the inter-domain case.

> For voice communications, there is no fixed source or destination 
> address (even assuming you could do reliable address filtering), and 
> in all likelihood, no fixed port. Thus, you'd have to assign this by 
> TOS byte or protocol (say, UDP) only. Highly spoofable.

One might know that a particular IP destination or source address 
within a given
administrative domain is the gateway to the "emergency call centre", the
"crisis management facility", "the 911 centre", "the NOC subnet", the
"VoIP subnet", or other such like.

So how much filtering and such one can do will directly vary with how 
thoughtful
a given domain has organised its networks, servers, and VoIP phones.  
Within
a single administrative domain, one can set policies throughout that 
domain,
so to the extent the networks/servers/IP-phones have been thoughtfully 
done,
one can deploy a corresponding amount of protective filtering.

Ran
[email-masked]