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

Feher Gabor wrote:
> 
> 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, 

I agree. It's a router with configured resource management (specifically,
configured queue management) as described in RFC 3290, with measureable
quantities defined in the MIB (RFC 3289). The question for BMWG would
be whether other quantities beyond those defined in the MIB are
valid metrics.

> 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.

Well, in diffserv what that means is that extra resources are added to or
removed from existing queues. There is nothing in diffserv that allows
you to measure anything flow-specific; all you can measure is a traffic
aggregate. I don't see how any metrics can be linked back to signalling.

> 
> 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.

Since diffserv is blind to microflows, this definition can be true
but it doesn't tell us anything about how to define a useful metric
for diffserv. Diffserv metrics must be defined for aggregates.

> 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.

As I said to Bob, I think it is too specific for the introduction. I would
suggest more generic intserv text.

> 
> 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?

Certainly not from diffserv, since diffserv is not in the resource
reservation business.

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