Subject: [Dime] Diameter Group: Type?

From: Erez Nassimi <[email-masked]>
Date: Mon, 24 Jan 2011 15:51:27 +0200

To whom it may concern:
======================

Dealing with the Diameter standard for more than 2 years, I always had the following question, I never dared to ask. But even after 2 years, I do not seem to have a good answer for it:

In RFC 3588, section 4.2 - AVP Data Formats, "Grouped" is defined as a "basic type". Doesn't it make more sense to set a flag for Grouped AVP in flags section? Group may be basic but it is not a real type. It's just an indication of a complex data structure.

If "Grouped" is defined as a flag, it will simplify any parser's work - and performance is such a rare resource.

Thanks in advance,
Erez Nassimi
[email-masked]<mailto:[email-masked]>
Desk : +972-9-77-86073
Cell : +972-54-7296230
Fax  : +972-9-77-61783

Did you know...?
With Amdocs' innovative new "Turbo Charging"<http://www.amdocs.com/Site/News/News+Articles/2008/Press+Releases/Turbo+Charging.htm> complex event processing technology, service providers can process thousands of charging events per CPU in real-time over low-cost hardware (like blade servers), all with the comprehensive functionality of Amdocs CES - Billing 7.5.

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

---

From: "David Lehmann" <[email-masked]>
Date: Mon, 24 Jan 2011 16:12:39 -0500

Erez,

I agree there should be a bit identifying the grouped AVPs.

--

David Lehmann

Ulticom, Inc.

856-787-2952

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erez Nassimi
Sent: Monday, January 24, 2011 8:51 AM
To: [email-masked]
Subject: [Dime] Diameter Group: Type?

To whom it may concern:

======================

In RFC 3588, section 4.2 – AVP Data Formats, “Grouped” is defined as a “basic type”. Doesn’t it make more sense to set a flag for Grouped AVP in flags section? Group may be basic but it is not a real type. It’s just an indication of a complex data structure.

If “Grouped” is defined as a flag, it will simplify any parser’s work – and performance is such a rare resource.

Thanks in advance,

Erez Nassimi

[email-masked] <mailto:[email-masked]> 

Desk : +972-9-77-86073

Cell : +972-54-7296230

Fax  : +972-9-77-61783

Did you know…?

With Amdocs’ innovative new “Turbo Charging” <http://www.amdocs.com/Site/News/News+Articles/2008/Press+Releases/Turbo+Charging.htm>  complex event processing technology, service providers can process thousands of charging events per CPU in real-time over low-cost hardware (like blade servers), all with the comprehensive functionality of Amdocs CES – Billing 7.5.

---

From: Avi Lior <[email-masked]>
Date: Mon, 24 Jan 2011 17:48:13 -0500

Well, Lets say you are right.  Don't you think that this is a bit late?

But I don't agree with you that a Group is not a kind of type and hence it could be a basic type (if you get my meaning)

Could you explain why do you think that a flag will simplify parsing?

-- Avi Lior
--Bridgewater Systems

From: Erez Nassimi <[email-masked]<mailto:[email-masked]>>
Date: Mon, 24 Jan 2011 08:51:27 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Dime] Diameter Group: Type?

To whom it may concern:
======================

In RFC 3588, section 4.2 – AVP Data Formats, “Grouped” is defined as a “basic type”. Doesn’t it make more sense to set a flag for Grouped AVP in flags section? Group may be basic but it is not areal type. It’s just an indication of a complex data structure.

Thanks in advance,
Erez Nassimi

Did you know…?
With Amdocs’ innovative new “Turbo Charging”<http://www.amdocs.com/Site/News/News+Articles/2008/Press+Releases/Turbo+Charging.htm> complex event processing technology, service providers can process thousands of charging events per CPU in real-time over low-cost hardware (like blade servers), all with the comprehensive functionality of Amdocs CES – Billing 7.5.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 25 Jan 2011 10:20:01 +0900

I agree with Avi, I think having the "grouped" information as a type
makes more sense than as a flag.
If the AVP code/vendor combination is unknown in the local dictionary,
there is no point in being able to "parse" the inside AVPs -- and I
think doing so (which would be possible with a "G"rouped flag in AVP
header) would actually do more harm than good.
As you wrote, parser's performance is a resource not to be wasted.
Therefore, what is the point of parsing the "inside" level of AVPs when
you don't understand the semantics of the grouped AVP that surrond them ?

Best regards,
Sebastien.

Le 25/01/2011 07:48, Avi Lior a écrit :
> But I don't agree with you that a Group is not a kind of type and
> hence it could be a basic type (if you get my meaning)
>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Dealing with the Diameter standard for more than 2 years, I always had
> the following question, I never dared to ask. But even after 2 years,
> I do not seem to have a good answer for it:
>
>  
>
> In RFC 3588, section 4.2 – AVP Data Formats, “Grouped” is defined as a
> “basic type”. Doesn’t it make more sense to set a flag for Grouped AVP
> in flags section? Group may be basic but it is not areal type. It’s
> just an indication of a complex data structure.
>
>  
>
> If “Grouped” is defined as a flag, it will simplify any parser’s work
> – and performance is such a rare resource.
>
>  
>
> Thanks in advance,
>
> *Erez Nassimi*
>
> [email-masked] <mailto:[email-masked]>***
>
> *Desk : +972-9-77-86073*
>
> *Cell : +972-54-7296230***
>
> *Fax  : +972-9-77-61783*
>
>  
>
> */Did you know…?/*
>
> With Amdocs’ innovative new “Turbo Charging”
> <http://www.amdocs.com/Site/News/News+Articles/2008/Press+Releases/Turbo+Charging.htm>
> complex event processing technology, service providers can process
> thousands of charging events per CPU in real-time over low-cost
> hardware (like blade servers), all with the comprehensive
> functionality of Amdocs CES – Billing 7.5.
>
>  
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Tue, 25 Jan 2011 12:41:03 +0100

On Monday 24 January 2011 14:51:27 Erez Nassimi wrote:
> Dealing with the Diameter standard for more than 2 years, I always
> had the following question, I never dared to ask. But even after 2
> years, I do not seem to have a good answer for it:
>
> In RFC 3588, section 4.2 - AVP Data Formats, "Grouped" is defined
> as a "basic type". Doesn't it make more sense to set a flag for
> Grouped AVP in flags section? Group may be basic but it is not a
> real type. It's just an indication of a complex data structure.
>
> If "Grouped" is defined as a flag, it will simplify any parser's
> work - and performance is such a rare resource.

The payload format of an AVP is uniquely identified by the AVP code. 
This means that if you receive an unknown AVP then the only thing you 
can do is to check the M-bit. If the M-bit is unset then you must 
skip it. If the M-bit is set then the message must be failed. Knowing 
if the unknown AVP is actually a grouped AVP does not help you.

If the hypothetical "G-bit" existed and was set on an unknown AVP why 
would the parser try to parse it?

The only area I can think of where the hypothetical G-bit would help 
is when trying to parse raw TCP streams without knowing the 
vendor/application/specification (eg. wireshark) and the G-bit could 
help to parse the grouped AVPs for human inspection.

/isj

---

From: Erez Nassimi <[email-masked]>
Date: Tue, 25 Jan 2011 14:02:40 +0200

Hi Avi & Sebastian - and thank you David for the support :-)

A few comments and clarifications:

1.       I don't think it's too late to add a "G"rouped bit in flags. Adding a "G" bit, should not revoke / replace Groups as type. It could be an additional feature.

2.       By saying "Group may be basic", I mean it may be a basic concept, but not a basic type.

3.       Syntax parsing the inside level of AVP's might be very useful, when there is a need to filter out irrelevant / incorrect messages as quick as possible.

4.       I think you would agree with me, that when syntax parsing a Diameter message (for example to verify validity of the message), it would be faster to identify a Group, without accessing any other data structure. That's what I mean by performance improvement.

5.       It's clear that when reaching a semantic analysis phase of the Diameter message, one needs ALL necessary info. Group or not Group, this is just a small part of the info in that phase.

6.       In any case, an additional "G" bit cannot harm anything; since in the worst case the Group type info still exists. So the "G" bit can be ignored.

7.       Also "calculating" the "G" bit when creating a message should not be a burden, since the info has to be there anyway.

I hope I'm more clear now.

Regards,
Erez Nassimi

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Jan 2011 15:07:47 +0200

Hi,

> 1.       I don't think it's too late to add a "G"rouped bit in flags. Adding a "G" bit, should not revoke / replace Groups as type. It could be an additional feature.

If it is not broken or severely confusing, then adding a new optional feature would just add new code and for no proper reason.

> 3.       Syntax parsing the inside level of AVP's might be very useful, when there is a need to filter out irrelevant / incorrect messages as quick as possible.

If you do not understand the grouped AVP, then depending on the M bit, I either do not care the whole grouped AVP or return an error pointing to the grouped APV, not the contents of it.

> 4.       I think you would agree with me, that when syntax parsing a Diameter message (for example to verify validity of the message), it would be faster to identify a Group, without accessing any…

I agree that it could be a performance enhancement. However, you would need to access the dictionary for the AVPs inside the group anyway. Depending how your per application dictionaries are handled, the performance gain might be subtle.

> 6.       In any case, an additional "G" bit cannot harm anything; since in the worst case the Group type info still exists. So the "G" bit can be ignored.

It can make stupid parsers to break who expect to receive a 0 in place of G bit..

> 7.       Also "calculating" the "G" bit when creating a message should not be a burden, since the info has to be there anyway.

Right.

- Jouni

> you may review at 
> http://www.amdocs.com/email_disclaimer.asp

---

From: Mark Jones <[email-masked]>
Date: Tue, 25 Jan 2011 14:32:57 +0100

Hi Erez,

The G-bit addition would not be backwards compatible with implementations of
existing Diameter applications. Looking at section 4.1 in RFC3588:

      The 'r' (reserved) bits are unused and SHOULD be set
      to 0.  Note that subsequent Diameter applications MAY define
      additional bits within the AVP Header, and an unrecognized bit
      SHOULD be considered an error.

This text appears to allow the definition of your G-bit in some future
Diameter applications (though I wonder if this is a bug in the RFC which
should read "subsequent Diameter versions"). However implementations of
existing Diameter applications SHOULD reject the AVPs with your G-bit set
and return a permanent failure of DIAMETER_INVALID_AVP_BITS.

How do you propose to make the G-bit addition harmless to existing
implementations?

Regards
Mark

---

From: "David Lehmann" <[email-masked]>
Date: Tue, 25 Jan 2011 10:04:29 -0500

I agree the RFC text should read "subsequent Diameter versions".
Applications should not be defining new flags.

--

David Lehmann

Ulticom, Inc.

856-787-2952

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Jones
Sent: Tuesday, January 25, 2011 8:33 AM
To: Erez Nassimi
Cc: [email-masked]
Subject: Re: [Dime] Diameter Group: Type?

Hi Erez,

The G-bit addition would not be backwards compatible with
implementations of existing Diameter applications. Looking at section
4.1 in RFC3588:

This text appears to allow the definition of your G-bit in some future
Diameter applications (though I wonder if this is a bug in the RFC which
should read "subsequent Diameter versions"). However implementations of
existing Diameter applications SHOULD reject the AVPs with your G-bit
set and return a permanent failure of DIAMETER_INVALID_AVP_BITS. 

Regards
Mark

---

From: "David Lehmann" <[email-masked]>
Date: Tue, 25 Jan 2011 10:13:16 -0500

In addition, I don't know if it is wise to consider it an error if
received reserved bits are nonzero.  It limits future expansion, like
the one suggested.

The IETF mantra is "Be strict when sending, but liberal on receiving."
Notice SCTP's spec on chunk flags:

RFC 4960, section 3.2:

  Chunk Flags: 8 bits

      The usage of these bits depends on the Chunk type as given by the

      Chunk Type field.  Unless otherwise specified, they are set to 0

      on transmit and are ignored on receipt.

--

David Lehmann

Ulticom, Inc.

856-787-2952

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Lehmann
Sent: Tuesday, January 25, 2011 10:04 AM
To: Mark Jones; Erez Nassimi
Cc: [email-masked]
Subject: Re: [Dime] Diameter Group: Type?

--

David Lehmann

Ulticom, Inc.

856-787-2952

Hi Erez,

Regards
Mark