Subject: RE: support for packet drop priority

From: Vijay Aggarwal <[email-masked]>
Date: Tue, 20 Jan 1998 14:59:50 -0500

> There is this recurring conception that "we can't let the host
do
	> the marking, 'cause they'll mark them all at high priority".
The cause for
	> alarm, is that the network downstream will be overrun. We must
keep in mind
	> that the first network that is not in the same admin. domain
as the host,
 > will be policing anyway (to protect their network). 

	I wonder if the reason why hosts would set high priority on all
traffic is
	because traditionally ISP's overbook, and the notion of hosts
setting
	high priority to all traffic, would give them an added
advantage.

	>	There is this recurring conception that "we can't let
the host do
	> the marking, 'cause they'll mark them all at high priority".
The cause for
	> alarm, is that the network downstream will be overrun. We must
keep in mind
	> that the first network that is not in the same admin. domain
as the host,
	> will be policing anyway (to protect their network). Even if we
told them
	> that we won't mark packets - they'd have to police. So - each
network has
	> the responsibility of protecting itself per its agreement with
its users.
	> Each user should have the responsibility of telling the
network how it wants
its traffic treated (since it knows best).

	The response to the above paragraph falls in line with my
previous question.
	Again each host would like its data to have preferential
treatement exactly during
	times of congestion and therefore it would set high priority for
all datagrams.

	True, that applications can be required to set the priority
correctly and it
	becomes a question of trusting applications. One way of
enforcing the trust is 
	by dollars and sence. If however policing and billing is done at
the access point 
	then applications would be sensitive to priority. Also ISP's who
are in the business
	of aggregation would have to take risks in estimating the
aggregation to priovide
	those priorities.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Jan 1998 07:08:10 +1100

At 08:09 AM 1/20/98 -0800, Yoram Bernet wrote:
>	There is this recurring conception that "we can't let the host do
>the marking, 'cause they'll mark them all at high priority". The cause for
>alarm, is that the network downstream will be overrun. We must keep in mind
>that the first network that is not in the same admin. domain as the host,
>will be policing anyway (to protect their network). Even if we told them
>that we won't mark packets - they'd have to police. So - each network has
>the responsibility of protecting itself per its agreement with its users.
>Each user should have the responsibility of telling the network how it wants

The answer this this is pricing plus user determined policy.

"Yes you can drive in the express lane for the same price as the
 slow lane" is a recipe for congestion given that self optimisation
 overrides any consideration of the resultant aggregate system
  efficiency.

"Yes you can drive in the epxcress lane for double the price of
 the slow lane" establishes a filter which bounds the number of
 aspirants to the fast lane. (And if there are more aspirants than
 lane space as a provider you can use the additional reveunt to
 construct a second express lane)

Exactly the same consideration holds here - IF you want to provide
an environment for differentiated service levels within a public
data network then you cannot impose differentiated service levels
on the user for certain network-defined services. IF you want
th provide a real capability for differentiated services then you
have to accept that the host will do the marking and the network
provider will undertake a pricing premium on packets marked
with elevated service indicators.

geoff

---

From: Yoram Bernet <[email-masked]>
Date: Tue, 20 Jan 1998 12:26:56 -0800

> IF you want
	[Yoram Bernet]  yes - or alternatively, use policing to downgrade
the priority (or mark as discard eligible) packets in excess of some allowed
capcity.

---

From: Yoram Bernet <[email-masked]>
Date: Tue, 20 Jan 1998 15:01:05 -0800

> 	One way to avoid having to not trust Hosts, is to have the edge
> router 
> examine the Protocol field and map it to a set of QoS that edge Router
> thinks is 
> appropriate. 
	[Yoram Bernet]  so - the granularity of qos that you're proposing,
is differnet servcie levels per protocol? what if my telephony app and my
web browser use the same protocol (e.g. ip). Useful qos should have a much
greater granularity than per protocol. (this is not saying "many levels of
priority or many service classes", just great flexibility in deciding which
traffic gets mapped to which priority). If we accept that this is a more
appealing qos model than per protocol, then it follows that it's going too
be difficult to have routers decide what "is appropriate".
> Any proprietary protocol be provisioned for some level of
> Qos. I do 
> understand that this is added mechanisms on the edges but it does take
> care of 
> uncooperative hosts.
	[Yoram Bernet]  how does it take care of uncooperative hosts? once i
learn that the router is giving priority to one protocol over another, i'll
just send my traffic using the higher priority protocol. the way to take
care of unccooperative hosts is to police per an agreement with the
customer, or to charge for excess traffic carried.
>  Once Edges start to provide this service then one
> can start to 
> talking about the ToS to be provided for different protocols. Using this
> mechanism 
> billing would be very deterministic.
> 
> 
> 
> 
> > -----Original Message-----
> > From:	Karl Auerbach [SMTP:[email-masked]]
> > Sent:	Tuesday, January 20, 1998 1:21 PM
> > To:	Yoram Bernet
> > Cc:	[email-masked]
> > Subject:	RE: support for packet drop priority
> > 
> > 
> > > alarm, is that the network downstream will be overrun.
> > 
> > (I'm agreeing with you...)
> > 
> > It's probably worth reminding ourselves that we already trust hosts to
> > do
> > some "self-sacrifice for the good of the whole" kinda things like TCP
> > slow
> > start and congestion avoidence.
> > 
> > But even if we trust hosts, we still gotta have policing -- else we'll
> > open up the newspaper (or get spam) selling OS/IP-stack software
> > patches
> > or widgets that go inline on the net interface cable that bump-up the
> > QoS
> > settings on outgoing packets.  [Maybe somebody should patent the
> > concept
> > to prevent the bad guys from doing it. ;-) ]
> > 
> > Since it is the applications in the user's host that will have to both
> > request and react to QoS settings, there will have to be a means of
> > communicating that information to whever the true QoS settins are
> > done. 
> > And that channel will have to be protected or policed against
> > manipulation. 
> > 
> > 		--karl--
> >

---

From: [email-masked]
Date: Tue, 20 Jan 1998 15:43:16 -0800

In addition, once packet are encrypted (via IPSec) from the end-station,
you won't be able to snoop on them or change them at intermediate hops any
longer.   Hence, they will need to marked in advance in order to describe
what traffic class they belong too.

/jsb

Karl Auerbach <[email-masked]> on 01/20/98 10:21:10 AM

Please respond to [email-masked]

To:   Yoram Bernet <yoramb @microsoft.com>
cc:   [email-masked] (James Binder/HQ/3Com)
Subject:  RE: support for packet drop priority

(I'm agreeing with you...)
It's probably worth reminding ourselves that we already trust hosts to do
some "self-sacrifice for the good of the whole" kinda things like TCP slow
start and congestion avoidence.
But even if we trust hosts, we still gotta have policing -- else we'll
open up the newspaper (or get spam) selling OS/IP-stack software patches
or widgets that go inline on the net interface cable that bump-up the QoS
settings on outgoing packets.  [Maybe somebody should patent the concept
to prevent the bad guys from doing it. ;-) ]
Since it is the applications in the user's host that will have to both
request and react to QoS settings, there will have to be a means of
communicating that information to whever the true QoS settins are done.
And that channel will have to be protected or policed against
manipulation.
          --karl--

---

From: [email-masked]
Date: Tue, 20 Jan 1998 16:01:31 -0800

Your assumption is that the edge router is the end of an ecrypted tunnel
since a encrypted packet application type would not be even visable to the
router. The only thing the router could do in this case is to police the
aggregate for a line.

/jsb

[email-masked] on 01/20/98 01:56:29 PM

To:   [email-masked], [email-masked]
cc:   [email-masked] (James Binder/HQ/3Com)
Subject:  RE: support for packet drop priority

patches
QoS
concept
     One way to avoid having to not trust Hosts, is to have the edge
router
examine the Protocol field and map it to a set of QoS that edge Router
thinks is
appropriate. Any proprietary protocol be provisioned for some level of
Qos. I do
understand that this is added mechanisms on the edges but it does take
care of
uncooperative hosts. Once Edges start to provide this service then one
can start to
talking about the ToS to be provided for different protocols. Using this
mechanism
billing would be very deterministic.

---

From: "Nachum Shacham" <[email-masked]>
Date: Wed, 21 Jan 1998 14:05:31 -0800

2 comments (1c each) on priority discarding of video layers:

>
>I agree that in this case my receiver does not have an incentive to do
>the backoff (since my video quality remains the same before and after
>the backoff)

The application does have an incentive to back off.  The reception fidelity
of layered depends not
only on the loss rate but also on where the losses are.  By dropping a
layer,
the application in fact concentrating all the losses in that layer,
(presumably
the least important one), hence
improving the fidelity of the remaining layers (assuming of course,
that no one takes advantage of the bandwidth
that was freed when the application backed off).

Multiple DPs can direct the loss hits across the layers, though it depends
on
the granuality
of interleaving of the packets that belong to different layers.  If layers
are finely
interleaved you can reasonably suspect that the congested router will find a
low priority packet to drop.  If the layers are sent in large bursts, there
may be
no low priority packet to discard at the router's buffer.

Nachum

==============================================================
Nachum Shacham
Tel: (650)859-5710
SRI International
Fax: (650)859-2844
333 Ravenswood Ave
[email-masked]
Menlo Park, CA 94025

---

From: [email-masked]
Date: Thu, 22 Jan 1998 11:24:52 -0800

In some respects, I think the real question we need to ask ourselves is are
we going t design for the normal case (ie., well behaved clients which are
possibly certified by some neutral 3rd party or Sun,Microsoft, ect.) and
try to protect against the exception case (i.e., hacker) or do you design
for the worst case scenario (ie., hacker) at the expense of the normal
case.

I think both have the pros and cons when you look at the complexity of the
solution.

/jsb

Zheng Wang <[email-masked]> on 01/22/98 08:06:47 AM

To:   [email-masked]
cc:   [email-masked] (James Binder/HQ/3Com)
Subject:  Re: support for packet drop priority

[email-masked] wrote:
>
> TCP is somewhat elastic. (Congestion decreases offered load.)
> Voice and Multimedia traffic (using UDP) "behave badly" (no elasticity).
> Whether or not it uses RSVP, it introduces a relatively rigid load to
> the net.   At least some people think this will grow and become
> important.
You are still missing the point. We *cannot* design the system based
on the assumption that end systems will follow the standard TCP
congestion control. People will hack if there are incentives to do so.
Cheers
Zheng
--
Zheng Wang
Bell Labs Lucent Technologies
http://www.bell-labs.com/user/zhwang

---

From: [email-masked] (Theimer, Thomas)
Date: Wed, 04 Feb 1998 15:57:16 +0100

Konstantinos,

>However, the isolation based on port numbers _is_ a solution. A first-order
>one, and as Jon said, a short-term one, perhaps, but I think
>it is a practical solution. The reasons:
>
>a) We have to trust  in a certain degree the TCP implementations. They
>are written by OS vendors, and an OS vendor cannot (for many political
>reasons) say that "I ignore slow-start and congestion avoidance".
>Of course there are cases where they try to play it smart and do their
>own variations, that eventually lead to more aggressive TCPs (in other
>cases they just have bugs; for details see Vern's TCP-related Sigcomm97
>paper). Also, there is surely the possibility that a hacker that has
>access to the kernel (or that uses a machine without kernel mode...)
>can write his own TCP code. Possible, but this cannot bring the Internet
>down, or even to make a big difference in a Mbps/Gbps link. This possibility
>existed all the time after 1988 when the slow-start stuff first got deployed.
>Besides, networks do not really operate on a stand-alone basis; the
>people that do the network monitoring can trace these "attacks", as long
>as they do not happen all the time.

Is TCP really the issue here ? TCP already has a lot of congestion control and backoff mechanisms, and I agree that it is reasonable to assume that TCP sources are well-behaved. Of course, there may be some improvements to TCP one could (and should) think of to improve TCP throughput and/or congestion control, but that's a different issue.

Should we not concentrate on UDP-based applications where such mechanisms are usually not available ? If so, then I see some problems in relying on UDP port numbers as these are often assigned through dynamic binding, so the network has no chance to know which application is behind most of the UDP ports. I expect this to apply to most interactive point-to-point applications using some form of audio or video streaming. Please correct me if I'm wrong, I did not check all possible UDP applications with respect to dynamic binding.

Taking all this into account, it seems to me that port numbers in general are not very useful in classifying packets according to the behaviour of their respective applications. An explicit indicator (e.g. TOS bits) is certainly much more useful, but may also be easier to manipulate.

Thomas