Subject: RE: Network "edge"

From: Peter Ford <[email-masked]>
Date: Mon, 12 Jan 1998 19:56:09 -0800

It appears the major points to be covered here are:

1) who should mark packets?

It would seem that applications would be the preferred entities to request
the marking of packets in terms of service requests.  How they are marked is
another question, and can be detemined by some network entity interpreting
the service request into some network "protocol".  That being said it should
be noted that the network has a presence in the bottom of the host
generating the packets in the first place.  The marking can be determined by
this part of the network and certainly  is a good place to do any media
based marking (802.1p, ATM VC, etc.) as well as IP TOS based marking.

2) who should police packets?

Anybody who does not trust who is sending him packets and needs to police.
This is true for the network entity in the bottom of a host taking in data
packets from multiple applications/transport entities/users and is probably
true for  entities that are the first hop router for some administrative
unit (corp net, ISP, receiving host, etc.).  If the set of apps/hosts and
first hop routers share an administrative domain and it is possible to set
policy for those apps and hosts, then the first hop routers may not need to
police.  The host is going to do some form of policing to fairly allocate
resources within the host's network entity.

cheers,

peter

> -----Original Message-----
> From:	Yoram Bernet 
> Sent:	Monday, January 12, 1998 3:26 PM
> To:	Rajesh Talpade; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: Network "edge"
> 
> see below, forward deleted...
> 
> > > A slight technicality ... NHRP clients can be present on hosts or
> > routers, 
> > > hence if the first router is to be bypassed, then the client must be
> > present 
> > > on the source host which will then be the ``edge'' which marks packets
> > for 
> > > appropriate service. 
> > 
> > You are not really suggesting that end-hosts be responsible for marking
> > and policing, are you ?
> 	[Yoram Bernet]  I am.
> >  An immediate incentive for end-hosts to
> > prioritize all their traffic is to grab more than their fair share of
> > _spare_
> > 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.
> I am of the opinion that we should give them an OS which secures access to
> these bits subject to network policy approval. Of course, the first hop
> router will still have to police, but - policing based on TOS bits is a
> lot
> less processing intensive than setting TOS bits based on some arbitrarily
> deep classification criteria.
> >  I assume there is general consensus that marking and policing 
> > should be entrusted to "first-hop" devices, instead of to end-hosts.
> 	[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.
> 
> > > However unless you go for one of the many 
> > > ``proprietary'' schemes for running NHRP over legacy LANs, most hosts 
> > > will be present on legacy LANs without an NHRP client and hence the
> > first hop
> > > router will not be bypassed.  
> > 
> > Ahh, this sounds like solution 'a', viz. nhrp wont exist mostly. 
> > 
> > > In an MPOA based network a convenient ``network edge'' is the LAN
> > switch/ 
> > > bridge between the host and the first router. Packet marking/
> > classification 
> > > at this point will allow the first router to be bypassed without 
> > > requiring this functionality to be setup in all hosts ... 
> > 
> > Diff serv was about marking/policing IP traffic. I am not sure if we
> > want to make the LAN switch/bridge IP-aware. 
> > 
> > > > 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. 
> > > > 
> > > 
> > > Not sure what you are suggesting here. 
> > > 
> > > a. Intermediate routers 
> > > are indeed the first hop router for hosts directly connected to them. 
> > > Typically one doesn't have routers which do not have any hosts (only 
> > > other routers) on directly attached interfaces ...
> > 
> > You point is true. However, consider an end-host 
> > with a first-hop router A. Traditionally, this first-hop router
> > would do the necessary marking/policing for this end-host. The
> > intermediate router B, which for simplicity reasons can be considered
> > to be the egress router to the ISP, provides aggregate control. So to 
> > get to the ISP, the end-host has to go thru router A and then router B. 
> > 
> > But now if the network is NHRP-capable, the end-host can establish a
> > direct path to router B. This router however is not capable of
> > policing/marking at the end-host level due to the aggregation effect
> > that we would like to use as we go away from the network edge. And so we
> > need to make these intermediate/egress routers aware of individual
> > end-host flows also, which may affect the scalability of the diff
> > services scheme.
> > 
> > hope things are clearer now.
> > 
> > rajesh.
> > 
> > 
> > -- 
> > Rajesh R. Talpade    [email-masked]   973 829-{4261, 5888(fax)}
> > Research Scientist, Bellcore, 445, South St, Morristown, NJ-07960

---

From: "Andrew T.Campbell" <[email-masked]>
Date: Mon, 12 Jan 1998 23:46:52 -0800

Peter:

I have a feeling that such talk on tagging and policing 
will inevitably lead down the slippery slope toward int-serv ;-) 

Before you know it diff-serv people will be calling for per-flow
queueing,
admission control and bounds on delay. At that point Fore's
stock price will sore.

Of course I jest - I'm keenly  interested to see if int-serv 
has a future in NGI. I believe pushing all good things to
the edge (whatever you definition of edge) will lead to
anarchy in the center.

Happy New Year!

Andrew

--
Andrew T. Campbell  
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project 
http://comet.ctr.columbia.edu/wireless