Subject: RE: [NSIS] Two kinds of requirements

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 16 Jan 2002 12:38:37 -0500

Hi, Mike:

Let me try.

For (a), RSVP has definitely some characteristics that can be used at the application layer on end-to-end basis. In fact, we have to look into RSVP, like SDPng, to examine all its features how we can exploit it for using in the application layer. We can then determine what we do when think that we need to develop a new QOS protocol.

However, it requires that RSVP needs to be used on end-to-end basis. If RSVP is used on end-to-end basis and if we all agree we do not need additional features (e.g., SDPng and/or others provide), it is definitely a good candidate to examine whether it meets all requirements.

What do we do when RSVP is not end-to-end? For example domain 1 = RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here it breaks down. One solution may be translation between RSVP and DiffServ. Then we loose the end-to-end picture.

Hope this may help to answer your questions.

Radhika

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 11:31 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

So, I'm really dumb here. Can somebody enumerate
the *specific* things that are broken with RSVP?
Before we run off designing new protocols, it
would be nice to know a) what things the current
protocols have problems with and b) whether the
current protocols are fatally flawed in the face
of those problems.

I know some in (a). I don't think they meet (b).

	Mike

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Steven Berson <[email-masked]>
Date: Wed, 16 Jan 2002 11:08:29 -0800 (PST)

On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

Regards,
Steve