[bmwg] Re: several comments on draft-feher-bmwg-benchres-term

[Feher Gabor <[e-mail]>]

Randy and all,

On Tue, 3 Dec 2002, Randy Bush wrote:

 > I also agree with Brian that they seem to see diffserv as
 > some kind of subset of rsvp-intserv.

Well, we're certainly aware of the difference between intserv and
diffserv, and we do not intend to deal with diffserv here in general. We
mentioned a protocol proposal (RODA, http://standards.ericsson.net/rmd/),
which is built on top of diffserv, but as this text seems to be misleading
we'll clarify this. To sum up, we are interesting only in routers that use
signaling protocols to perform resource reservations.

 > It seems odd to me that there is a concern with "different
 > resource reservation protocols" that includes some stuff
 > that is in research papers, not IETF RFCs, standards or
 > informational. Interestingly enough, one of these, Boomerang
 > shares a first author with this document. I think mentioning
 > it on a par with RSVP in a WG document is a blantant ploy to
 > try to create some kind of standards visibility for someone's
 > research project. And a rather back-handed one. Who is shipping
 > Boomerang? What IETF WG owns it?

Randy, we found your words unfair.

Our intention with the resource reservation benchmarking terminology &
methodology drafts was to create a general framework, which can be used
for both existing (standard) and future reservation protocols. We hope
this is ok so far.

As we wanted to compare our definitions to the protocols we looked at IETF
standard protocols (RSVP, ST-II+) as for the existing ones. We also
examined non-standard protocols (Boomerang, YESSIR, SDP, Ticket) in order
to be more general and future-proof (certainly we're not saying, that
these protocols are the future).

It's true that the authors contributed in the Boomerang development, but
we don't see why is it a problem:
- we just gained experience on res.resv. protocols
- we mentioned here *all* the related protocol proposals we know,
Boomerang is just one of them

Thus mentioning Boomerang is not a "blatant ploy", especially that the
Boomerang project is over for years and mentioning it here makes us
absolutely no advantage (nor did it before).

About research papers: we think the first phase in a protocol's life is
usually a research paper: e.g. as far as we know RSVP was first published
in IEEE Network Magazine, in September of 1993, well before its first RFC
appear - 1997 September.

 > The issues section of 6.1.4 tells us about how Boomerang works.

Ok, we can refine it and also we don't necessarily have to mention the
protocol's name in the next version. Anyway, we think that such a
functionality (i.e. endpoint without a protocol stack) is relevant and
might be deployed later on.

 > The issues section of 6.1.5 the last sentence is an opinion
 > about architectural choices, which seems out of place in
 > a benchmarking document, particularly one one benchmarking
 > terminology.

Well yes, if you think so, we can delete it. We just wanted to show, why
do we need two different reservation orientations and what are the reasons
behind the orientations.

 > Similarly, I am a bit concerned about the issues section of
 > 6.1.6, but if Bob feels it is appropriate here, I'll bow
 > to his greater expertise.

This is similar to the previous issue.

 > Section 6.2.2 talks about Premium Data Packets as those
 > distinct from Best Effort. The diffserv WG heard a lot
 > of discussion on a topic that some network operators
 > believe is important which is to be able to treat data
 > packets differently from Best effort and *worse* than
 > best effort. "Premium" is a misnomer in that case.

That's true. We'll update the definition.

 > In the same section, the authors perpetuate a common
 > mistake by equating multi-field classification to IP
 > 5 tuple or ToS field classification. "Multifield" was
 > always meant to refer to any arbitrary set of fields
 > and that's what the diffserv WG docs say. They give the
 > five-tuple as an *example*.

Thanks, we'll alter the definition.

 > I found 6.4.2 and 6.4.3 confusing. If a router needs to
 > classify packets, it has to classify all the packets
 > that pass through it since it can't know apriori which
 > are "premium" unless it's done by port or something. Then
 > "marking" is mentioned in 6.4.3 as if it had already
 > been discussed.

Yes, we have to clarify this, too.

What we meant is the following: there are proposals to mark the
non-best-effort traffic packets so that the best-effort packets can be
quickly forwarded without the longer multi-filed classification. We
intended to refer to this, but agree, this was not clear.

 > Also, the forwarding time needs to
 > include scheduling time which is quite variable, but
 > yet that is not called out here. On the other hand,
 > this may not be important if it is the resource reservation
 > capabilities that are being benchmarked. If that's so,
 > why is this document talking about forwarding time?

In many router implementations signaling processing has effect on the
packet forwarding performance, and vice versa, that's why this topic is
included. Certainly we have to get rid of packet scheduling, queuing
delays during the measurements, but we think this goes to the methodology
part and not to the terminology.

 > It seems like 6.4.4 is actually describing a metric that
 > ought to be important, given the title of the document.
 > Thus, the waffle words on time period seem a bit too waffly.
 > This is a good place to make a recommendation. After all,
 > there's some time period where the emergence of the
 > reservation is critical.

We think it would be better to make recommendation in the methodology part
that is more close to the devices. We experienced that this time period
might depend on the actual protocol, or the time when the measurement was
started. So therefore, we think a general introduction is enough for this
metric. Probably we should rewrite this part a bit indicating that it
would be detailed in the methodology part.

On Sat, 7 Dec 2002, Randy Bush wrote:

 > given the review comments on this one, should i consider this draft
 > back in the wg's court and waiting for a new version?

Yes, certainly we'll update the draft according to the comments. We also
plan to show it to the nsis guys, and look for their remarks. And
certainly we're looking for your reply and notes, too.

Regards,
Gume, Krisztian 

_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg