Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00

From: Stefan Winter <[email-masked]>
Date: Fri, 13 May 2011 14:41:09 +0200

Hi,

> Jacni>: While we opened the door in this way for additional IANA
> activities. I have a fear that everytime we will need to request a
> value for -id,
> then give the recommended definition of -name accordingly, and vise
> versa? ;-)

I understand your concerns. Another option to do this properly would be
to use RFC5777 - it allows traffic filter, QoS, or even time-of-day
definitions. That should cover a lot of use cases.

The obvious drawback (is it a serious one?) is that it pulls in Diameter
attribute format, which might mean it's not very easy to implement in a
RADIUS server.

I wonder what people think of this...

>     I don't see an issue with that unless one would want to have different
>     session Id's for different traffic groups in the same accounting
>     ticket
>     - but I have a hard time thinking of a reason for that; after all all
>     the counted Octets and Packets belong to the same user session,
>     and can
>     thus share the same session id.
>
>
> Jacni>: For example, two clasess v4 and v6, over single access service,
> there may be cases that the dynamic QoS or bandwidth policy changes
> (class-specific)
> are requested by users,say, through portal, then initiate/executed by
> the server side, the
> -id is needed.

I'm not sure I understand what you mean. Let me construct an example.
Did you mean

- User logs in over single PPPoE session, gets dual stack connectivity
- NAS has Accounting ID 0xf00ba, and two accounting classes, one for v4
and one for v6
- mid-session, IPv6 gets new QoS parameters (DSCP -> higher) and needs
to be billed separately from that moment on

If that's the use case, I still don't see why the accounting ID would
need to be different from the initially allocated one. It's still the
same session, and thus the same session ID.

An accounting packet could start with two accounting blocks:

IPv4 - DSCP 0
IPv6 - DSCP 0

and when the change happened, adds the third block for traffic class

IPv6 - DSCP x

The block "IPv6 - DSCP 0" will stop incrementing at that point, because
all subsequent traffic will be DSCP x. But it can still be there, and
accurate billing can be produced from it - so no reason why a
Acct-packet-global accounting ID would be insufficient.

Or maybe I got your use case wrong :-)

Stefan

>
>
> Cheers,
> Jacni
>
>
>     Greetings,
>
>     Stefan Winter
>
>     --
>     Stefan WINTER
>     Ingenieur de Recherche
>     Fondation RESTENA - Réseau Téléinformatique de l'Education
>     Nationale et de la Recherche
>     6, rue Richard Coudenhove-Kalergi
>     L-1359 Luxembourg
>
>     Tel: +352 424409 1
>     Fax: +352 422473
>
>
>

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473