Subject: RE: support for packet drop priority

From: Vijay Aggarwal <[email-masked]>
Date: Tue, 20 Jan 1998 16:56:29 -0500

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

	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.

> -----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
> 
> 
> > 	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.
> 
> (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: Karl Auerbach <[email-masked]>
Date: Tue, 20 Jan 1998 15:01:01 -0800 (PST)

> router examine the Protocol field and map it to a set of QoS that edge
> Router thinks is appropriate.

You are thinking of applications as being static partners in the QoS game.

Once we get beyond today's first generation QoS aware applications, we are
going to see that it is going to be a game of mutual adjustments -- an
application will request a QoS, the network may say "no" (either initially
or later as the network conditions change), and the application will have
to adapt.

In the RTP/RTCP world that I work in, there are feedback channels and
applications can change their choice of codec depending on the QoS they
are actually obtain.

In addition, even within a single stream, there may be times when an
application needs to pump up the QoS -- for example when a snipper of
music is inserted into a voice presentation.

		--karl--