Subject: RE: [NSIS] Requirements draft and RSVP analysis draft

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Wed, 21 Nov 2001 09:02:39 -0600

Hi Hemant,

Just a short initial comment: Please note that the points in
draft-greis-rsvp-analysis-00.txt are not necessarily all 100% my
opinion. I explained this also in the introduction to the draft, i.e.
these are just "frequently heard complaints". I tried to be somewhat
unbiased in gathering them, and I see it as an educational exercise to
weed out the points that are invalid (or to potentially add others).
Your comments are a good starting point.

> - Why is RSVP is too "heavy" on end terminals? It think that 
> RSVP does not have any complexity implications on end 
> terminals, which merely have to send and receive Path and 
> Resv messages.

This refers mostly to very low-end terminals like certain devices in
wireless/cellular networks. Of course, cellular phones for example are
getting fancier all the time, and RSVP would be just one of many
protocols, but we also have to think of other devices, e.g. small
surveillance devices, where battery power may be a very important issue.
In these devices, it may not be desirable to send periodic refreshes for
example. However, I do agree that this is one of the "weaker" points
(other opinions are welcome). The main complexity is certainly in the
network.

> - About soft state: I think it needs to be reworded to imply 
> that RSVP uses "explicit" refresh messages. This can actually 
> be done implicitly. "Soft" state is not a problem in my 
> opinion. If any protocol creates a state for the transient 
> packet session inside the network, the state has to be soft. 

I'm not sure which definition of soft state you are using. I define soft
state as state which needs to be explicitly refreshed, or otherwise it
will expire, i.e. the wording "soft state" already implies that RSVP
uses explicit refresh messages. That is also the definition used in RFC
2205. Everything else is hard state in my opinion.

Thanks,
Marc

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

---

From: Nemeth Krisztian <[email-masked]>
Date: Thu, 22 Nov 2001 02:24:47 +0100 (CET)

Hi NSIS,

> > - Why is RSVP is too "heavy" on end terminals? It think that 
[...]
> wireless/cellular networks. Of course, cellular phones for example are
[...]
> (other opinions are welcome). The main complexity is certainly in the

I guess the good strategy usually is to move the complexity out of the
network to the terminals (e.g. TCP). So if speaking against RSVP, in my
opinion the required router complexity should be emphasized, rather than
the end-system complexity.

Krisztian

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 28 Nov 2001 09:45:13 +0100

> the end-system complexity.

For the low-end terminals, the power consuption for sending is a problem 
not the complexity of the protocol, so the number of refreshes should be 
minimized. (various mechanisms are possible such as the mention explicit or 
implicit refresh).

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.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]