RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt

["ASH, GERALD R, ATTLABS" <[e-mail]>]

Hi Robert,

Thanks a lot for the careful review.  Please see responses below. 

> -----Original Message-----
> From: Hancock, Robert [mailto:[e-mail]] 
> Sent: Tuesday, March 06, 2007 8:51 AM
> To: nsis
> Subject: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt
> 
> hi,
> 
> here are some comments. most are minor.
> 
> robert h.
> 
> ==============================================================
> ==========
> ====
> 
> general: i think the document needs to be checked for consistency of
> 2119 capitalisation. some musts/shoulds should be MUSTs/SHOULDs and so
> on. (I think actually the words themselves are right except 
> where noted below.)

OK.
 
> p9 para 2 line 5 ("but they ..."): needs editorial fixing
> 
> s4.3 para 2 (and similarly later): surely not-understood non-mandatory
> parameters MUST be ignored? is there any meaningful sense in 
> which they
> could not be?

OK.

> s4.3.1 para 2 "mathematically complete": i have looked for a reference
> for this for a while - imagine my disappointment when the citation
> [WROCLAWSKI] resolves to 'TBD'! 

Agreed.  I've tried to run down a reference to the work that supports
this statement, but so far without success (I've emailed the possible
source of the analysis but so far haven't gotten a reply).  Lacking an
appropriate reference, the related text/reference will be removed.

> s4.3.1 final para: i would use a word other than 'composed' for the
> first three instances ('input' and 'output'?)

These is quite common terminology used in other RFCs to mean
'accumulated' values, see for example RFC 2210
http://www.ietf.org/rfc/rfc2210.txt?number=2210 and search the word
"composed" (object names even use the word).
 
> s4.3.2 para 2: if the delay includes queuing, i would add this
> explicitly to the 2nd sentence. (currently, it implies it is 
> limited to
> propagation and processing delays, and it is not obvious 
> whether queuing
> is a type of processing.) Also, it needs to be clear if it is the mean
> queuing delay or some other statistic of the delay (since 
> variability is
> covered in the next paragraph under jitter).

The third sentence in the paragraph says "The mean delay reflects the
variable queuing delay that may be present."  I think that clarifies
your issues?
 
> s4.3.2 2nd-to-last para: "an QSPEC" --> "a QSPEC"

OK.
 
> s4.3.3 para 1: i don't see how the second two sentences here relate to
> TH directives. Could they be deleted? I think the message is already
> stated earlier in the document.

I agree that this text may be a bit repetitious.  However, there was a
very long discussion regarding this text (see NSIS archive) and it was
agreed that this text was the resolution of the discussion.  I don't
think we can delete it.
 
> s4.3.4: I could not follow this section. In particular, the example in
> 4.4 has the QNI populating the PHB value, not the downstream QNE as
> stated here.

Good point.  I think the particular sentence could be clarified as
follows:

"Note that PHB class is normally set by a downstream QNE to tell the QNI
how to mark traffic to ensure treatment committed by admission control,
however, setting of the parameter by the QNI is not precluded."
 
> s4.4 (and later): there should be some reference to the QoS-NSLP
> specification to clarify the meaning of the word 'tunnel'. It could
> refer to tunneling the data+signalling, tunneling the signalling only,
> or hiding the signalling from the interior some other way 
> (e.g. using an
> NSLPID which isn't understood in the interior). I'm not suggesting
> actually defining/discussing all these in the QSPEC document, just
> noting that the tunnel words as a shorthand may be misleading 
> to people
> who don't have all the context. You could use a word like 'hiding' and
> refer to 3.3.1 of Qos-NSLP and 7.2 of GIST.

OK, agree with your suggested re-phrasing.
 
> s5.1 last para: presumably this is saying that an edge node could use
> both techniques, but not for the same traffic (what would be the point
> of that?)

Good question.  This text was also added after much discussion on the
list.  I agree that it isn't clear how both techniques would be used at
the same time for the same flow.  We can add text to that effect,
however, I think it should be confirmed that these techniques are not
intended to be used *at the same time for the same flow*.  Perhaps
Georgios could verify this.
 
> s5.2.1 para 1: presumably only understood parameters MUST be examined?

Yes, good point.  This text needs to be clarified to say that only the
TMOD parameter and parameters marked with M=1 MUST be examined.
Parameters marked with M=0 SHOULD be examined if understood by the QNE.
 
> s5.2.2 last para: could say 'provides a bound' rather than unreliable.

OK.
 
> s5.2.5: i think there should be some notes here pointing out 
> that there
> is some intelligence needed in mapping the E flags etc. from the inner
> to the initiator Qspec. (Note that this *not* the same as 
> Qspec mapping,
> but there is at least some mapping to do - for example, there 
> may be no
> direct match between the parameters in the local and initiator Qspecs,
> but that does not mean that no E flags should be raised in 
> the latter.)

Agreed.  Any text suggestions would be appreciated here.
 
> s5.3: i think that rather than describing the two cases as
> sender/receiver-initiated, it would be better to describe these two
> cases as a 2-way transaction and a 3-way transaction. It just 
> so happens
> that up to now it's natural to use the 2-way handshake for a
> sender-initiated reservation and the 3-way handshake for a receiver
> initiated one, because then in each case the first message in the
> handshake is sent by the flow sender and this can set up the routing
> state. However, logically GIST can (attempt to) set up the 
> routing state
> in the reverse direction, so you can for example have a
> receiver-initiated reservation set up with the 2-way 
> transaction. (this
> would be the natural way to do a reservation for an inbound flow to a
> mobile node from a mobility anchor, for example.) I don't think this
> changes any of the text other than giving things different 
> headings and
> using the terms QNI/QNR rather than sender/receiver in the 
> descriptions.

OK with me to re-title these sub-sections as you suggest.
 
> s5.3.2: Case 4 --> Case 3?

Right.
 
> s5.3.5: I would delete the clause about pre-emption being based on the
> Priority parameter. It implies that pre-emption is somehow
> deterministic, whereas I would say that it is always a matter of QNE
> policy, which could take all sorts of things into account (and the
> values of the priority parameter in various messages are just some of
> these).

Point taken.  The sentence could be changed as follows:
"A flow can be preempted by a QNE based on QNE policy, where a decision
to preempt a flow may account for various factors such as, for example,
the values of the QSPEC preemption priority and defending priority
parameters as described in Section 6.2.8."  

> s5.4 para 1: surely update to all QNEs is needed only if the parameter
> is always used with M=1 and there is no fallback in response to error
> conditions. (As written, this is much too pessimistic.)

Right.  This text should be deleted, a point that was raised on the list
at http://www1.ietf.org/mail-archive/web/nsis/current/msg07653.html (see
also the related comment at
http://www1.ietf.org/mail-archive/web/nsis/current/msg07654.html).
 
> s6.2.3 (and later): i would move the definition of the 'indeterminate'
> encoding earlier, otherwise one is left wondering what this 
> word means.
> [there are also two typos here, flagand and flagflag.]

OK on all.
 
> s6.2.5/6.2.6: remove references to values being measured in
> microseconds.

Good catch.
 
> s6.2.12: i think the initial layout diagram is confusing. it 
> implied to
> me that the PHB encoding is always a 6 bit field. Actually, 
> the initial
> diagram should be of a 16 bit field, and then three (rather than two)
> layout options, for the three cases of prescribed value, 
> value set, and
> non-standard. And shouldn't the 'X' in the second two layout options
> actually be a '1'?

Good comments.  This should be clarified as follows:

Single PHB:

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DSCP      |0 0 0 0 0 0 0 0 0 0|
   +---+---+---+---+---+---+---+---+

Set of PHBs:

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DSCP      |0 0 0 0 0 0 0 0 1 0|
   +---+---+---+---+---+---+---+---+

Single non-standard PHB (experimental or local):

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PHD ID CODE      |0 0 0 1|
   +---+---+---+---+---+---+---+---+

Set of non-standard PHBs (experimental or local):

    0                   1          
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PHD ID CODE      |0 0 1 1|
   +---+---+---+---+---+---+---+---+

Thanks,
Regards,
Jerry

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