Re: [bmwg] more comments on draft-ietf-bmwg-benchres-term

Dear All,

Thanks for the comments!

>Apart from Bob's comment, I am bit concerned that the authors are
>slightly confused about diffserv. The text under "Issues" in 6.1.3
>really misses the point - the way you look at resource management
>in a diffserv domain is simply different from how you look at it
>in a reserved-flow model. A BMWG draft for diffserv domains might
>be a good idea, but that is a separate discussion.
I agree that benchmarking DiffServ domains is a completely different 
discussion, and we do not intend to investigate it together with IntServ. 
However, it is an interesting question, wether a DiffServ router is a 
router that supports resource reservation or not. Actually, I would say, 
that in itself it is not a resource reservation capable router, however if 
a DiffServ router is extended with a signaling protocol, like RODA 
(formally Load Control) then it already supports resource reservations. 
(Resources are allocated (namely) to certain traffic flows) And this is why 
DiffServ is mentioned in the draft.

Therefore, I think, first we should agree on what is a resource reservation 
session. In the draft we wrote:

6.1.1 Unicast Resource Reservation Session

    Definition:
       The term unicast resource reservation session (or shortly
       reservation session) expresses that two end-nodes explicitly
       request the network nodes, which forward their data flow, to
       assign special QoS treatment for data packets belonging to the
       flow.

Here we would like to emphasize that there must be a signaling protocol 
that controls the resource reservation.

I would like to hear your opinion about this!

>Worse, the first paragraph of the Introduction
>
> >    The IntServ over DiffServ framework [1] outlines a heterogeneous
> >    Quality of Service (QoS) architecture for multi domain Internet
> >    services. ...
>
>greatly exagerrates the importance of RFC 2998, which is merely a way
>of munging together diffserv-incapable hosts and diffserv domains. I don't
>see why this paragraph (which is essentially an opinion piece) is needed.
>IMHO it should simply be deleted.

Well, we have just simply want to give focus to the resource reservation 
signaling, since the whole draft is around this topic. Maybe it was a wrong 
decision to start with the relation of DiffServ and IntServ so if most of 
you disagree then it can be changed.

Bob wrote:
>    Zeroth-order comment: this document contains terminology and
>     concepts that overlap significantly with the current NSIS work.
>     Perhaps there ought to be some consistency here?

Definitely! Actually we would like to have opinions from the NSIS group 
also. We created this draft because we found that there is no terminology 
about the basics of resource reservation at all! So I think this draft 
could be more general than a terminology for benchmarking. So lets create 
consistency! I need your comments!

Does anyone know similar attempts from different working groups?

Best regards,
Gabor 

_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg