Subject: rsvp and IP precedence large carrier networks

From: Subramaniam Vincent <[email-masked]>
Date: Tue, 11 Nov 1997 09:27:27 -0800 (PST)

Yoram Bernet at Microsoft send this message out on the rsvp mailing list.
I thought this might be interesting to the intserv list at well.

vince

---------- Forwarded message ----------
Date: Tue, 11 Nov 1997 07:18:38 -0800
From: Yoram Bernet <[email-masked]>
Cc: [email-masked]

> Yoram,
>
> Thanks for your message. Would appreciate if you could clarify
> on what you meant by the above point on the use of RSVP in large carrier
> networks ?
	[Yoram Bernet]  I meant that large carriers may choose to adopt or
not to adopt RSVP in their networks, over a period of time. I would expect
that the amount of state that could be required in large networks would be a
disincentive to implement RSVP in these networks. I'm also not sure it's
necessary (or even useful) for them to adopt RSVP.

	Instead - these networks can support class of service, in a
stateless fashion (by use of the IP precedence bits in each packet, for
example). In this case, one could imagine the following scenario:

	Mid-size corporate campuses could support RSVP within their
networks. In communications betwen these peripheral networks, RSVP messages
between communicating endstations, would pass transparently through the
carrier network. These messages would however, be subject to the standard
RSVP admission control in the peripheral networks.

	As part of invoking sender traffic control (which occurs when a RESV
succeeds in getting all the way back to the sender), the sender could
elevate the priority of packets sent on the reserved flow (by setting the IP
precedence bits to a value appropriate for the service type reserved). As a
result, those flows which passed RSVP style admission control in the
peripheral networks, will be prioritized accordingly, in the carriers
network. Some may argue that IP precdence should be set at network
boundaries, not at hosts - that's a separate argument :-)...

	By adding policy at key nodes (in particular at egress and ingress
points from/to the carrier's network), managers of the peripheral networks
can limit the number of flows admitted to the higher priority classes based
on such factors as user ids and availability of bandwidth in the various
clases in the carrier network. This works well with a staitc provisioning
model in which the carrier offers its customers pre-provisioned bandwidth
between certain endpoints.

	In this model, we have reservations in the peripheral networks, and
a form of aggregation into priority clases in the carier networks. The
latter makes sense in the carrier networks, where statistics help assure
that at any time, there will be a reasonable load in each priority class. In
the periphery, where frequency and numbers of callers coming and going is
smaller, true reservations help assure that resources are not transiently
overcommitted.

	That's my $.02
	Yoram

> Vince
>
> >
> > As for the synergy with ATM qos - as the RSVP messages transit islands
> > of various layer-2 technologies in the end to end network, capable nodes
> > are responsible for translating the layer-2 independent flowspecs into
> > the appropriate action for the layer-2 technology. So just as, in an
> > ethernet hop, a flowspec would cause a packet scheduler to be set up
> > according to the flow requirements, in an atm hop, a VC would be
> > established having the appropriate flow characteristics.
> >
> > RSVP is misunderstood. It is not a panacea - it is one of the tools that
> > can bring together many of the valid disparate qos technologies. This is
> > the vision towards which Microsoft is working.
> >
> > Yoram
> >
> > > -----Original Message-----
> > > From:	Sunny Fan [SMTP:[email-masked]]
> > > Sent:	Sunday, November 09, 1997 12:08 AM
> > > To:	[email-masked]
> > > Cc:	[email-masked]
> > > Subject:	Re: switch vendors
> > >
> > > Hi, Joachim Martillo
> > > 	You say RSVP is useless in packet switching environment,
> > > then where should it be used? I used to believe it's developed from
> > > ethernet and to competite with the QoS of ATM. Is that right?
> > > Regards,
> > > Sunny Fan
> > > 11/9
> > > ----------
> > > > From: [email-masked]
> > > > To: [email-masked]; [email-masked]
> > > > Subject: Re: switch vendors
> > > > Date: Saturday, November 08, 1997 8:35 PM
> > > >
> > > > RSVP/Integrated Services constitutes one of the silliest possible
> > > > ways to do anything for which it is touted in any packet switching
> > > > environment, but shared ethernet media probably count as
> > > > an exceptionally wrong place to try to do this sort of thing.
> >

---

From: Gunnar Karlsson <[email-masked]>
Date: Wed, 12 Nov 1997 19:47:35 +0200

I have the following problem (sorry if it has been settled before, I
cannot browes the full archive):

When doing fast packet forwarding, it would be useful to be able to tell
a datagram apart from a packet belonging to a flow *before* it has been
classified. 

Here are the reasons:

- Knowing that the packet is part of a flow tells the forwarding engine
which header fields are relevant for the classification (simply
destination, or also source address, protocol type and port number).

- In case the forwarding engine gets overloaded, it might need to
discard incoming packets. Those would preferrably be datagrams since the
QoS of flow-packets is not known prior to the classification (the
discard could of course obey drop precedence).

So, I would simply like one of the ToS bits to tell whether a packet is
a (best effort) datagram or part of a (QoS) flow. 

-Gunnar

---

From: [email-masked] (Hyogon Kim)
Date: Wed, 12 Nov 1997 14:00:34 -0500 (EST)

Gunnar,

>a (best effort) datagram or part of a (QoS) flow. 

This relates to a gradual deployment scenario. My understanding is (correct 
me if I'm wrong) that our assumption in diff-serv is that a user who bought
some profile is basically a QoS user. Otherwise she is best-effort. In 
Clark approach, the best-effort user's packets are all marked "out-of-profile", 
while a QoS user's are marked based on her profile. In all cases packets
are not dropped at the meter.  In Jacobson approach,
all QoS user's packets are marked "in-profile" (if her rate goes beyond
that packets are simply dropped at the edge), while best-effort user's
packets are all marked "out-of-profile" and fed to network. 

So the answer is, you already have the bit: drop preference.

-- Hyogon
------------------------------------------------------------------------------
Hyogon Kim ([email-masked])	       		       |        (201) 829-4728
Research Scientist				       |           MCC 1B-225B
Internet Architecture Research Laboratory	       |      445 South Street 
Bell Communications Research			       |  Morristown, NJ 07960
------------------------------------------------------------------------------