Subject: [NSIS] Requirements draft and RSVP analysis draft

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Tue, 20 Nov 2001 08:54:40 -0600

Hi all,

This is just to let you know that the two drafts I previously mentioned
are now available in the Internet drafts directory:

http://www.ietf.org/internet-drafts/draft-greis-qos-signaling-requiremen
ts-00.txt

Abstract: This draft proposes a set of requirements for QoS signaling
protocols. These requirements are derived both from past experience with
existing QoS signaling protocols as well as new challenges which arise
for QoS signaling e.g. from mobile, wireless and cellular networks.

http://www.ietf.org/internet-drafts/draft-greis-rsvp-analysis-00.txt

Abstract: The purpose of this document is to describe commonly known
problems with RSVP as a basis for future work on RSVP, which may result
in an improved version of RSVP.

Note that both drafts focus only on the signaling aspects, i.e. you will
not find any discussion related to the service provisioning mechanisms.

Any comments are of course very welcome!

Marc

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 28 Nov 2001 11:43:48 +0100

Hi Marcus

>> My question from a reqirements point of view is, what are 
>> he initiators of 
>> the refresh (end-terminals, any man in the middle like base stations, base 
>> station controllers, etc.

I think that this depends on the applied QoS signaling scenario, i.e.,
edge to edge QoS, end to edge QoS, or end to end QoS.

Best Regards,
Georgios

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Nov 2001 09:01:28 -0000

Dear all,

It seems reasonable to say that deciding where to put 'proxies' (better name should be possible) in any real deployment is an implementation issue (as John implies).

However, that it should be possible to use a proxy in the first place surely has to be decided at the requirements stage. There are (at least) two reasons (additional to those below) why proxy-ability doesn't come as a free bolt-on later:

1. in some scenarios, working out how to find the right proxy may be non-trivial and may require support from the signalling protocols (we know this from bitter experience with rsvp-like protocols). we need to decide if this support is a requirement.

2. using proxies could totally change the interpretation of the security aspects of the qos signalling being used (who is authenticated and to whom? the proxy? does the proxy proxy the authentication as well?) So, the security requirements at least need to be written with this flexibility in mind (if the flexibility is something that we want - which I think we do).

regards,

Robert H.

ps i know my disclaimer looks weird as an attachment, but at least it's easier for you to skip over that way.

> -----Original Message-----
> From: Brian Williams [mailto:[email-masked]]
> Sent: 29 November 2001 00:27
> To: Marcus Brunner
> Cc: john loughney; [email-masked]; [email-masked]
> Subject: RE: [NSIS] Requirements draft and RSVP analysis draft
> 
> 
> On Wed, 2001-11-28 at 21:05, Marcus Brunner wrote:
> > 
> > 
> > --On Wednesday, November 28, 2001 11:23 AM +0200 
> [email-masked] 
> > wrote:
> > 
> > > Hi Marcus,
> > >
> > >> My question from a reqirements point of view is, what are he
> > >> initiators of the refresh (end-terminals, any man in the middle
> > >> like base stations, base station controllers, etc.
> > >
> > > One possibility would be to have a proxy function in the network.
> > > Where it is actually deployed would be much more of an
> > > implementation issue.
> > >
> > > br,
> > > John
> > >
> > 
> > IMHO, a proxy function needs to be thought through from a protocol, 
> > probably even more from a information exchange point of 
> view. I don't think 
> > this an implementaion issue only. (A proxy keeps state we 
> need to prevent 
> > to have too much state somewhere else.
> Proxies can also effectively act as interworking points. 
> Consider if the
> two hosts support different QoS mechanisms (eg one uses "NSIS
> signalling", and the other does DS marking). Proxies therefore may be
> important for an overall QoS framework.
> 
> > 
> > Marcus
> > 
> >

---

From: [email-masked]
Date: Thu, 29 Nov 2001 11:49:46 +0200

Hi Robert,

> It seems reasonable to say that deciding where to put 
> 'proxies' (better name should be possible) in any real 
> deployment is an implementation issue (as John implies).

We could come up with a better name, but I guess that isn't
a huge issue at the moment.
 
> However, that it should be possible to use a proxy in the 
> first place surely has to be decided at the requirements 
> stage. There are (at least) two reasons (additional to those 
> below) why proxy-ability doesn't come as a free bolt-on later:
> 
> 1. in some scenarios, working out how to find the right proxy 
> may be non-trivial and may require support from the 
> signalling protocols (we know this from bitter experience 
> with rsvp-like protocols). we need to decide if this support 
> is a requirement.
> 
> 2. using proxies could totally change the interpretation of 
> the security aspects of the qos signalling being used (who is 
> authenticated and to whom? the proxy? does the proxy proxy 
> the authentication as well?) So, the security requirements at 
> least need to be written with this flexibility in mind (if 
> the flexibility is something that we want - which I think we do).

Agreed.  This is something that I tried to capture in the 
charter.

br,
John