Subject: Re: Network "edge"

From: Scott Bradner <[email-masked]>
Date: Sun, 11 Jan 1998 18:10:55 -0500 (EST)

--
b) it is not sufficient to make "first-hop" routers responsible
for marking bits and policing mechanisms. Intermediate routers
should be able to do this if they get traffic from end-hosts. 
--

or egress routers? or any boundry router?

Scott

---

From: Yoram Bernet <[email-masked]>
Date: Sun, 11 Jan 1998 17:47:39 -0800

or hosts... 

yoram

> -----Original Message-----
> From:	Scott Bradner [SMTP:[email-masked]]
> Sent:	Sunday, January 11, 1998 3:11 PM
> To:	[email-masked]; [email-masked]
> Subject:	Re: Network "edge"
> 
> --

---

From: [email-masked]
Date: Mon, 12 Jan 1998 09:04:41 -0800

Rajesh,

At first glance, I think you need look at this with a slight change of
perspective  --  It might be that the best place to request diff-services
is where the application is running ( For example, Is it video,  audio, or
some other data type and what  are data characteristics like delay and
jitter needed).   Whereas, the policy should be applied to the request by
either the first hop device or other intermediate devices if it chooses not
do so.   It would then be up to hosts to request what Type Of Service they
want and it would be up to intermediate devices (either first hop or other)
to apply policy to the request.  Also, in light of things like IPSec, these
values will not be able to be snooped or changed in flight.

If you take ISSLL over 802 media, SBM for example is being done such that
the request for service could be modified and merged to lower classes of
service if so desired.  In addition, the RAP working group is looking at
ways in which to off-load the policy decision where needed.

If Differentiated services are requested by a protocol like ISSLL SBM (and
maybe even use RAP somehow), then the requests could be policied and
enforced by any intermediate device which cared about it if the data stream
didn't match the flow.  Also, because the requests could be merged, the
state in the intermediate devices could be minimized to some level.  This
would allow a router to return to the host what values to use for
TOS/Precedence and then policy those values for range violations.

More specifically, if you look at some ideas, a policy element would be
included in the ISSLL SBM request which would identify you (say an x.509
cert.) which would be out-soured to a RAP server to validate your request.
If you are allowed to access Class of Service, then the corresponding
values which should be used for this traffic would be set in the response.

The only issue which would need further work and research is how much
policy can be applied at the first hop router and how much can slide into
the interior devices.

/jsb

/jsb

Rajesh Talpade <[email-masked]> on 01/11/98 01:22:30 PM

To:   [email-masked]
cc:    (James Binder/HQ/3Com)
Subject:  Network "edge"

Solutions for differentiated services seem to indicate a strong
preference for pushing complexity towards the edges rather than
towards the core. But what is exactly the network edge ? If it is
indeed the first-hop router, then what happens when and if
NHRP gets deployed, and hosts can bypass their (traditional)
first-hop routers to get to the egress router.
Two solutions seem fairly obvious:
a) NHRP wont be around to create this problem :-)
b) it is not sufficient to make "first-hop" routers responsible
for marking bits and policing mechanisms. Intermediate routers
should be able to do this if they get traffic from end-hosts.
Any comments ?
Rajesh.

--
Rajesh R. Talpade    [email-masked]   973 829-{4261, 5888(fax)}
Research Scientist, Bellcore, 445, South St, Morristown, NJ-07960

---

From: Ed Ellesson <[email-masked]>
Date: Mon, 12 Jan 1998 16:32:34 -0500

At 03:23 PM 1/12/98 -0500, Rajesh Talpade wrote:
>
>You are not really suggesting that end-hosts be responsible for marking
>and policing, are you ? An immediate incentive for end-hosts to
>prioritize all their traffic is to grab more than their fair share of _spare_
>bandwidth. I assume there is general consensus that marking and policing 
>should be entrusted to "first-hop" devices, instead of to end-hosts.
>

Rajesh, 

I think you have to be careful here about lumping marking and policing
together.  The host is actually often in the best position to mark packets,
since it can know best what the traffic class is for each packet.  In an
intranet, there can be more control of end user behavior, with permissions
to mark packets for high priority "premium" service provided by queries to
a directory of packet marking policy which is centrally administered for
the corporate intranet.  The same is true of VPN's and extranets.  On the
public internet, ISP's can protect their service to other customers, and
discourage customers from marking packets for premium service when they
have not contracted for such service,  by policing and packet re-marking at
their ingress points.  Customers can make sure they stay within their
contract by policing and remarking at the LAN egress point.  

So, yes, policing and packet marking will be done by edge devices, but
marking will also definitely be done at hosts. In fact, with IPSEC
implemented in end systems, there are scenarios where traffic marking must
be done by hosts, since the port numbers, which provide important traffic
classification clues, are encrypted in that case, and are not available for
that purpose at the network edge devices.  

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115

---

From: Yoram Bernet <[email-masked]>
Date: Mon, 12 Jan 1998 15:58:05 -0800

below...

> From:	Rajesh Talpade [SMTP:[email-masked]]
> Sent:	Monday, January 12, 1998 3:52 PM
> To:	Yoram Bernet
> Cc:	[email-masked]; [email-masked]; [email-masked]
> > > and policing, are you ?
> > 	[Yoram Bernet]  I am.
> > >  An immediate incentive for end-hosts to
> > > bandwidth.
> > 	[Yoram Bernet]  Yes, but - you can police in first hop routers to
> > prevent them from actually succeeding in doing so. The fact is - there's
> no
> > stopping a thief... As soon as app vendors realize that they can get
> > preferential treatment by setting these bits, they'll work out how to do
> it.
> 
> Doesnt this mean we cant trust end-hosts ?
	[Yoram Bernet]  you can trust end hosts to the extent that you can
trust users of end hosts... bottom line is - you can't trust anyone. even if
i told you that you could trust end hosts - would you believe me and decide
that you didn't really need to police me?

> > >  I assume there is general consensus that marking and policing 
> > 	[Yoram Bernet]  There is not. See above comment. We will be
> > releasing a proposal shortly on how host based signaling and
> TOS/precedence
> > bit setting can be integrated with the work in the diff-serv and policy
> > working groups.
> 
> The only case I can see marking by end-host being useful (other than the
> special intra-lan case where everyone is trusted) is if
> the end-host wants to indicate to the first-hop device about which
> data is more important than other.
	[Yoram Bernet]  i see this as a very important case. for example -
wouldn't it be nice if you could give my audio data preference over my web
surfing data?
>  The first-hop device will still have
> to mark/unmark the traffic and do the policing.
	[Yoram Bernet]  I beleive that the first hop device should still do
policing, as will many other devices along the way (likely any boundary at
which the sender is likely to benefit by lying to the next hop)...

	I'm not convinced about the need to mark/unmark though... if all
carriers agree on a universal interpretation of TOS/precedence, why
shouldn't the host be privy to this marking as well? In that case, the host
might as well do the marking. If on the other hand, each domain has its own
interpretation of TOS/prcedence bits (which would seem unfortunate), then I
agree with you.

> Oh well, I look forward to your proposal.
	Regards
	Yoram

---

From: Raj Yavatkar <[email-masked]>
Date: Mon, 12 Jan 1998 16:33:40 -0800

At 06:51 PM 1/12/98 -0500, Rajesh Talpade wrote:
>> prevent them from actually succeeding in doing so. The fact is - there's no
it.
>Doesnt this mean we cant trust end-hosts ?

You can't trust anyone, but you can use first hop routers to ensure that
end systems don't cheat. That way, you have to define mechanisms that
discourage/prevent cheating any way. I think that is Yoram's point.
>> releasing a proposal shortly on how host based signaling and TOS/precedence
>data is more important than other. The first-hop device will still have

marking will be done by the end hosts based on user/app input; first-hop
device will still do policing at aggregate level.

Raj

>Oh well, I look forward to your proposal.

-----------------------------------------
   Raj Yavatkar                                       
   Communication Architecture Lab           [email-masked]
   Intel Corporation, JF3-206                     voice -- 503-264-9077
   2111 NE 25th Avenue,  Hillsboro, OR 97124