Subject: [Dime] Last Call: draft-ietf-dime-qos-parameters (Quality of Service Parameters for Usage with the AAA Framework) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 3 Nov 2008 07:12:44 -0800 (PST)

The IESG has received a request from the Diameter Maintenance and 
Extensions WG (dime) to consider the following document:

- 'Quality of Service Parameters for Usage with the AAA Framework '
   <draft-ietf-dime-qos-parameters-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-11-17. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16087&rfc_flag=0

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

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 4 Nov 2008 06:28:26 +0100 (CET)

>4.1.  Parameter Header
>
>   Each QoS parameter is encoded in TLV format.
>
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |M|r|r|r|     Parameter ID      |r|r|r|r|         Length        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Why the odd position of the parameter ID? This would additional
processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)).
I'd say tack the four 'r's on the right there onto the left group.
What's wrong with making it a grouped AVP instead of this binary-packed
format?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 4 Nov 2008 10:58:54 +0100

Hi Jan,

> processing time to pull it out (p = (b[0] & 0x0F) | (b[1] & 0xF0)).

Ain't it:    p_id = ((b[0] & 0x0f) | b[1]);

> What's wrong with making it a grouped AVP instead of this 

These parameters are also usable outside Diameter, thus the
compact coding that allows them to be more independent of
underlying protocol. Use of groups would be uneasy with e.g.
RADIUS that this document lists as one of the possible
protocls to take advantage of these QoS parameters.

cheers,
	Jouni

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 4 Nov 2008 13:07:32 +0100 (CET)

>Ain't it:    p_id = ((b[0] & 0x0f) | b[1]);

That will only work as long as the four reserved bits *as received* are 
always zero. Given that they are reserved for future use, I would not 
bet on them to be zero for all eternity.

---

From: <[email-masked]>
Date: Tue, 4 Nov 2008 14:21:40 +0100

> On Tuesday 2008-11-04 10:58, [email-masked] wrote:
  ^               ^               ^
  +---------------+---------------+
   1. octet        2. octet

> >Ain't it:    p_id = ((b[0] & 0x0f) | b[1]);

Ups.. Forgot the left shift ;-)

p_id = (((b[0] & 0x0f) << 8) | b[1]);

(assuming b is e.g. u_char* and network byte ordering is used)

I still think the coding is ok for these two 12 bits values.

Jouni

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 4 Nov 2008 14:35:58 +0100 (CET)

>> On Tuesday 2008-11-04 10:58, [email-masked] wrote:

Oh 12... it seemed like 8. Now why on Earth would one use
12 bits? 8 or 16 seems much more sensible.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Nov 2008 13:40:03 +0200

Hi Jan, 

>Why the odd position of the parameter ID?

We re-used the encoding developed in the NSIS working group. 

> This would 
>additional processing time to pull it out (p = (b[0] & 0x0F) | 
>(b[1] & 0xF0)).

The processing time is a piece of cake. 

>I'd say tack the four 'r's on the right there onto the left group.

But if it looks better we could do that. 

>What's wrong with making it a grouped AVP instead of this 
>binary-packed format?

We asked the group whether they have an opinion about the encoding.
Since the encoding of the attribute will not be processed by the AAA
server itself but rather by an component within the AAA server
responsible for policy based admission control (and that code has to be
written anyway) it did not matter what the encoding actually is. Hence,
we stayed with this encoding. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Nov 2008 13:47:53 +0200

We shouldn't get too excited about this aspect. 

As described in my other mail we did re-use these parameter encodings
from NSIS as they have done the work on QoS (and these parameters again
re-use some other work throught the IETF). We said that we wouldn't want
to develop our own QoS parameters in this group and I still believe that
this was a good decision. We just re-use and reference. 

Nevertheless, if the group has a strong opinion about the header
parameter encoding then we should talk about that. We discussed the
issue of a Diameter AVP encoding vs. the encoding we have today. We
decided to stick with the encoding we have today. 

Changing the encoding of the header is a fairly small change and hence I
am open to that.

Ciao
Hannes

>-----Original Message-----
>From: ext Glen Zorn [mailto:[email-masked]] 
>Sent: 06 November, 2008 06:49
>To: [email-masked]; [email-masked]; 
>Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]; [email-masked]; 'Glen Zorn'
>Subject: RE: [Dime] Last Call: draft-ietf-dime-qos-parameters 
>(Quality of Service Parameters for Usage with the AAA 
>Framework) to Proposed Standard
>
>Jouni Korhonen [mailto://[email-masked]] writes: 
>
>...
>
>> These parameters are also usable outside Diameter, thus the compact 
>> coding that allows them to be more independent of underlying 
>protocol. 
>> Use of groups would be uneasy with e.g.
>> RADIUS that this document lists as one of the possible protocls to 
>> take advantage of these QoS parameters.
>
>That's easy: take RADIUS off the list.  The idea that the 
>design of Diameter applications or AVPs should be constrained 
>by the limitations of RADIUS is simply absurd; further, this 
>is a very good argument for not publishing this document at 
>all.  If RADIUS compatibility was a major goal then this work 
>should have been done in radext.
>
>...
>
>