Subject: [Dime] comments on <draft-ietf-dime-diameter-qos-02.txt>

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 23 Nov 2007 19:24:07 +0100

Hello,

Please find some comments/suggestions on draft-ietf-dime-diameter- 
qos-02.txt.
Thanks for conisdering them.

Francois

QoS Signaling Proxy
===============
I understand there is agreement that the document should allow (and  
explicitly discuss) scenarios involving Proxy QoS signaling on the  
DCA-client (as opposed to relying on end-to-end QoS signaling).
See:
	* http://www1.ietf.org/mail-archive/web/dime/current/msg02036.html
	* http://www1.ietf.org/mail-archive/web/dime/current/msg02033.html,
	* http://www1.ietf.org/mail-archive/web/dime/current/msg02022.html)
In particular, :
	- in the Push mode, we would want the DQA-S to be able (in the QIR)  
to instruct the DQA-C to initiate QoS signaling on behalf of sender  
(ie behave as QoS-signaling sender proxy).
	- in the Pull mode, we would want the DQA-S to be able (in the QAA)  
to instruct the DQA-C to terminate QoS Signaling on behalf of the  
receiver (ie behave as QoS-signaling Receiver Proxy).

However, this does not seem to be covered in the updated version.
Can we assume it will be covered in subsequent versions?
Would it help to propose text for this?

Comments:
=========

* section 3.2.2:
As discussed above, I am interested to see "QoS signaling" being  
supported/discussed in the Push mode (via use of QoS-Signaling sender  
proxy).
However, as the text of 3.2.2 currently stands (ie there is no  
mention of QoS signaling proxy) and as the Figure 4 currently stands  
(ie it does not show any QoS signaling in the Push mode), the  
following statement seems out of place in section 3.2.2:
"Note that the reserved QoS resources reported in the QIA message MAY be
    different than those initially authorized with the QIR message, due
    to the QoS signaling specific behavior (e.g., receiver-initiated
    reservations with One-Path-With-Advertisements) or specific process
    of QoS negotiation along the data path.
"
This text will become relevant when QoS signaling sender-proxy are  
actually discussed.

* section 5.1 & 5.2:
should the messages in ABNF format not be called "<QoS-Authorization- 
Request>" and "<QoS-Authorization-Answer>" instead of "<QoS-Request>"  
and "<QoS-Answer>"?

* section 7.1:
In general, when resource reservation is performed for a SIP session,  
it is a good idea to use SIP Preconditions (RFC3312) so reservation  
can be done before ringing. Shouldn't the picture in figure 23 assume  
illustrate call flow with RFC3312 Precondition?

* section 7.1:
Figure 23 illustrates a case where QoS-signaling uses sender- 
initiated signaling for one direction of teh call and receiver- 
initiated signaling for the other direction. As the objective of the  
figure is to illustrate how the various steps (SIP signaling, QoS  
signaling , QoS Authorisation,..) are tied/synchronised together (as  
opposed to showing all the sophistication of the QoS signaling), I  
would recommend you illustrate operation with receiver driven  
signaling in both direction. It will convey the main point more clearly.

* section 7.1
the text description uses "Host A/Host B" while the figure uses "End- 
host requesting QoS" and "Correspondent Node". You want to use one  
set of terms in both.

* section 7.1:
The call flow shown with NSLP applies equally to RSVP without any  
modification. I would like to see this be made explicit. One way  
would be to:
	* replace "QoS NLSP Query" by "QoS NSLP Query or RSVP Path"
	* and replace "QoS NLSP Reserve" by "QoS NSLP Query or RSVP Resv"

* section 7.1:
The current text only describes half of what is shown in the picture  
(ie with QoS reservation in the first direction). I suggest we add at  
least a bit of text saying to the effect of  "same happens in reverse  
direction".

* section 7.2:
The text:
" Note that the examples above show a sender-initiated reservation from
    the End-Host towards the corresponding node and a receiver-initiated
    reservation from the correspondent node towards the End-Host."
should be removed from 7.2 as the call flow in 7.2 does not involve  
any QoS signaling.

* section 7.x:
I'd recommend including call flows here involving QoS signaling proxy  
(eg Push with QoS Signaling sender proxy). Again, let me know if  
you'd like proposed text.

* I suggest you add [RFC2205] in Informational References since RSVP  
is mentioned multiple times.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime