Subject: RE: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony)

From: [email-masked]
Date: Thu, 21 Feb 2002 13:35:32 +0100

Marcus, 

> I prefer the term session.
> 
> 
> So the requirement:
> The NSIS protocol should be able to request QoS for more than one
> session at once. The sessions might originate at different 
> applications or 
> different instances of the same application, or the same 
> appication. However, 
> the data path MUST be the same, and the whole request MUST be 
> granted at once 
> or denyed at once.
> 
> Opinions?
Assume that the instantiation of the nsis signaling in this case will be an end-terminal. 

In this case the requirement would state that the end terminal must know that the data path is the same for all micro-flows, ie that no load balancing or anything is happening in the network. This is impossible for the end-terminal to know. I understand why you would like to state such a requirement but I do not see how you could implement it.

An alternativ is for the network to take care of the problem, which forces complexity in the network (as Georgios indicated as well). Another alternative is to force per-microflow signaling (which we probably want to avoid). And yet another, to accept that the host does not know the path and the network does not want the compexity to split and merge signaling packets and thus accept that the signaling and data path is not the same. With all the implications this have.

Anders

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 21 Feb 2002 14:10:30 +0100

> An alternativ is for the network to take care of the problem, which
> forces complexity in the network (as Georgios indicated as well).

I agree.

> Another alternative is to force per-microflow signaling (which we
> probably want to avoid). And yet another, to accept that the host does

Per-microflow signaling is possible when you use aggregation of
reservations. In this case the number of reservation states and
signaling requests can be reduced for all ASs which are covered by the
aggregate (except the aggregate start- and endpoints) to a scalable
amount. However, this requires nsis support for reservation aggregation.

> not know the path and the network does not want the compexity to split
> and merge signaling packets and thus accept that the signaling and data
> path is not the same. With all the implications this have.

Right. I also thought about the idea some time ago. But processing
logically dependent requests by the control entities requires a lot
of extra complexity. So let the end-systems implement their 
application-specific logic for deciding about the results of 
multiple requests.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097