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

["Hancock, Robert" <[e-mail]>]

hi jerry,

a couple of followups: 

> -----Original Message-----
> From: ASH, GERALD R, ATTLABS [mailto:[e-mail]] 
> Sent: 08 March 2007 20:55
> To: Hancock, Robert; nsis
> Cc: ASH, GERALD R, ATTLABS
> Subject: RE: [NSIS] some comments on draft-ietf-nsis-qspec-15.txt
> 
> 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).

maybe 'input composed' and so on; but i'm not that fussed
(i managed to work it out anyway)

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

it's actually that sentence which caused the confusion. wouldn't it
be easier to have the second sentence say
"This delay results from the combination of speed-of-light propagation
delay, 
packet processing, and queueing." ?

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

i agree the text is needed; it's just that it seems you already
have it in section 4.1.1 (in a more complete form, in fact)
which also seems the right place for it.

*** end of followup

robert h.

>  
> > 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.ht
> ml (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
> 

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