Subject: Re: QoSSIG BOF - now what are we trying to do?

From: Bob Braden <[email-masked]>
Date: Wed, 2 Feb 2000 00:48:11 GMT

*> 
  *> Hi all,
  *> 
  *> I have now seen various interpretations of what a QoSSIG WG should do; a
  *> few think of DiffServ (and/or IntServ), some (including me - or is it just
  *> me?  ;)  ) would like such a WG to work on stateless QoS signaling to make
  *> the most efficient use of the network without actual network-side QoS
  *> provisioning (this could be done with a "tweaked" RSVP, PTP or any other
  *> protocol that encompasses QoS-signaling) and others consider it a forum
  *> for a lightweight and more scalable resource reservation protocol. Even
  *> moving the problem to an intra-domain level as opposed to end2end has
  *> been requested.
  *> 

Stateless signaling.  Hmmmm... maybe next we should work on bufferless
reliable transport protocols.

Seriously, the QoS architecture currently proposed that uses E2E RSVP
signaling and aggregation in the core of the network *is* stateless
signaling, at least in the parts of the network where statelessness is
both necessary and possible.

So, we are done.

That is, as long as you don't want to do multicasting.  People's
estimate of the importance of multicasting varies; I suspect it is not
large on your radar screen.  Why do you think telephony over IP 20
years from now will be simply a rerun of what you have been doing for
100 years?

Bob Braden

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 2 Feb 0 12:58:05 JST

Bob;

> reliable transport protocols.

You can send packets repeartedly until acknowledged with no windows.
The standard protocol is called TFTP.

So, we are done.

What's next? Shall we disband IETF or the transport area of it?

> both necessary and possible.

What do you mean?

The currently proposed CoS architechture has nothing to do with QoS.

> That is, as long as you don't want to do multicasting.

Multicast is not an only factor to make QoS assurance stateful.

							Masataka Ohta

---

From: Joakim Bergkvist <[email-masked]>
Date: Wed, 02 Feb 2000 09:14:44 +0100

> both necessary and possible.

From current RSVP proposals stateless would mean not to touch.We are talking about
nodes doing CAC without signaling states. If this is done in RSVP you must give me
a pointer where to find it.

> years from now will be simply a rerun of what you have been doing for

You can do multicast reservations even without signaling states.. What you can't do
is multicast with heterogenous destinations.

I still think we need a forum in the IETF in which to discuss these issues. It may
well be that stateless nodes could be integrated in RSVP but RSVP was not designed
for this.
With this in mind I beleive a good startingpoint would be a  framework to outline
the possibilities without the legacy of RSVP.

/ Jocke

>
> _______________________________________________
> Boomerang mailing list
> http://soha.ttt.bme.hu/mailman/listinfo/boomerang

---

From: Steven Berson <[email-masked]>
Date: Wed, 2 Feb 2000 09:16:52 -0800 (PST)

On Wed, 2 Feb 2000, Joakim Bergkvist wrote:

> From current RSVP proposals stateless would mean not to touch.We
> are talking about nodes doing CAC without signaling states. If
> this is done in RSVP you must give me a pointer where to find it.

There is our work on state aggregation for RSVP, ``Aggregation of
Internet Integrated Services State'' which describes how to greatly
reduce the amount of signalling state.  Quoting from the draft:

   This draft describes how to provide Internet Integrated Services for
   both unicast and multicast traffic with greatly reduced state
   requirements.  We concentrate primarily on Controlled Load type
   service[10], which reserves bandwidth but not delay or jitter, though
   our approach should be more generally applicable (see [7] for a
   related approach).  With our approach, the amount of scheduler state
   is bounded at all nodes for both unicast and multicast traffic.  For
   unicast traffic, full classifier state and setup protocol state are
   stored only at the edges of the network.  In the interior of the
   network, no unicast setup protocol state is stored, and only a
   bounded amount of classifier state is used.  For multicast traffic, a
   minimal amount of additional classifier state and additional setup
   protocol state is used in the network interior.

The draft is available from the RSVP web page:

		http://www.isi.edu/rsvp

> You can do multicast reservations even without signaling states.

It appears that you have read the draft.

> What you can't do is multicast with heterogenous destinations.

But what you can do is to store only the minimum amount of state and
only at the specific points of heterogeneous branching.  Doing this
allows you to support multicast with heterogeneous destinations.
 
> I still think we need a forum in the IETF in which to discuss
> these issues. It may well be that stateless nodes could be
> integrated in RSVP but RSVP was not designed for this. With this
> in mind I beleive a good startingpoint would be a framework to
> outline the possibilities without the legacy of RSVP.
> 
> / Jocke

Regards,
Steve