Subject: RE: [NSIS] NSIS Requirements: grouping microflows

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 29 May 2002 13:44:16 +0200

Hi Roland

But this requirement can be seen as a more general 
definition of the refresh reduction method used in 
RSVP!

Thus, I do not know why you should remove it?

Best regards,
Georgios

-----Original Message-----
From: Roland Bless [mailto:[email-masked]]
Sent: woensdag 29 mei 2002 12:23
To: [email-masked]
Subject: [NSIS] NSIS Requirements: grouping microflows

Hi,

I've got a comment to
Open issue
14) add "support grouping of microflows"

If I remember correctly, Georgios supported this requirement
due to its usefulness for refreshing states. IMO this is 
better solved by a refresh reduction method such as the
proposed one for RSVP. 
Therefore: shouldn't we remove this requirement?
Though grouping microflows in a request is really complex
due to handling of failed requests for single flows,
it might be useful to have a list of reservation-IDs 
for error messages such as a release due to failure.
But this seems to be an implementation specific optimization
rather than a functional requirement.

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

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

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 31 May 2002 11:57:38 +0200

Hi Georgios,

> Thus, I do not know why you should remove it?

As said before, if used in a request for initially 
establishing the reservations, it is difficult to 
handle situations when some of the grouped reservations
fail. This would be typically best solved by the application
itself and a good example to apply the end-to-end design
principle. However, there may be other message types in which
grouping several reservation-IDs can be useful, but I doubt
that we need it as a functional _requirement_.

Regards,
 Roland