Re: Working Group Last Call: RMD QOSM

Hi Phil, 

thank you for your review. Please see my answers below,

Best regards, Attila


Hi,

A few comments (certainly not a full review!)

S2 terminology
I think these should be functional definitions. Eg if the ingress node
is congested your definition implies that it doesn't congestion mark.
DiffServ (& PCN) use functional definitions

Attila: I will change the title of S2 to "Terminology and Functional definitions"

I think you should add a definition of NSIS aware & unaware. I found it
quite confusing. At the moment when one of these terms is mentioned the
doc often gives a semi-definition. Nsis unaware seems to mean something
like, unaware of nsis signalling, but some sorts of nsis state & rmd ops
are possible. You can tell from the last sentence that I didn't get a
good view of what it meant! For instance I found S4.3.2 , the 2 paras
about probing, confusing. 

Attila: You are right, we need to clarify it

S3.1 top of page 7: measurement-based, "once an admission decision is
made, no record need be kept". Surely the ingress needs to keep a
record, because it has to police

Attila: OK, we will correct it

3.2.3 first para
"The reason for this.." I didn't understand your reasoning. I think this
is something to do with the <QoS Desired> parameter, which you assumed
I'd know what it does.

Attila: It would like to say that in order to support AF in its full generality, the RMD-QOSM domain has to support the use of at least two token buckets. 

3.2.3 
6 different possible signalling schemes is a lot for one document? 
Items 3 & 4 form a pair (different sever congestion operation) as do
items 5 & 6. but items 1 & 2 don't - why? 
Wasn't sure what "per aggregate" meant (4.3.1 didn't help) - I guess
this is just standard nsis terminology?

Attila: These case come from the combination of the reservation and congestion handling methods and support of aggregated reservations. These signaling schemes are very and they were part of the original concept.

Items 1 & 2 form a pair, from the point of view that they are using the same severe congestion method, i.e., severe congestion with data marking, but they are using the two different types of measurement based admission control mode, see Section 4.3.2. We will clarify this.

What we mean by per aggregate, is aggregated reservation. The way of how the binding of end-to-end sessions is performed is described in the QoS-NSLP draft. We will try to improve the description in Section 4.3.1.

PCN is only mentioned in one sentence in S3.2.3. do you (or rather the
iesg) think this is enough? (I'm personally ok with this level.)

4.6.1.6.2.1
"one DSCP for severe congestion indication for each of the AF  classes".
Contradicts 3.2.3 where say 0 or 1 AF class?

Attila: You are right, I will change for: "for each of the AF classes that can be supproted by RMD-QOSM"

S5 security
Should there be separate considerations for your 6 different possible
signalling schemes?
Why have you got SHOULDs? Should they be MUSTs?

Attila: We will calrify this in the security section.

App A - good that this is now an example in Appendix ( I seem to
remember it was in the main text before)

Fig A.1 - why is there no event for moving from severe cong state to
cong notification state.

Attila: This is because the goal of the used severe congestion algorithm is to directly change the behaviour from severe congestion state to normal state. We will clarify this.


Best wishes,
phil

{ -----Original Message-----
{ From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf
Of
{ Jukka Manner
{ Sent: 27 October 2008 06:46
{ To: NSIS Working Group
{ Subject: [NSIS] Working Group Last Call: RMD QOSM
{ 
{ 
{ Dear all,
{ 
{ This message starts the Working Group Last Call on the RMD QOSM.
{ 
{ http://tools.ietf.org/wg/nsis/draft-ietf-nsis-rmd/
{ 
{ Please submit your comments within two weeks, by Monday November 10th.
{ 
{ Regards,
{ Jukka
{ 
{ ps. And, please people, be a bit more active. Thanks.
{ _______________________________________________
{ nsis mailing list
{ nsis at ietf.org
{ https://www.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis