Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Statistics design proposal for 0.9.2 (Tomek Mrugalski)
2. Re: RSOO bug in 0.9.1 (Templin, Fred L)
3. Re: Statistics design proposal for 0.9.2 (Marcin Siodelski)
4. Re: Statistics design proposal for 0.9.2 (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Apr 2015 15:18:13 +0200
From: Tomek Mrugalski <[email protected]>
To: kea-dev list <[email protected]>
Subject: [kea-dev] Statistics design proposal for 0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi all,
One of the features planned for 0.9.2 are statistics. Here is the
proposed design: http://kea.isc.org/wiki/StatsDesign.
This design is not the most advanced or fully featured. It's a
compromise between what we could do and what actually can do in the
limited timeframe of 0.9.2 release.
The basic concept is that the statistics are currently simple, but they
can evolve over future releases. Whatever evolution path we'll choose,
the API should remain stable, if possible.
Please review and comment.
Tomek
------------------------------
Message: 2
Date: Tue, 14 Apr 2015 19:08:32 +0000
From: "Templin, Fred L" <[email protected]>
To: Wlodek Wencel <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] RSOO bug in 0.9.1
Message-ID:
<2134f8430051b64f815c691a62d9831832e49...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hello Wlodek,
See attached for the kea server configuration file plus a tcpdump packet capture
of the Relay-forward and Relay-reply messages. The packet captures show that
the Relay-forward includes a Vendor-Specific Information option with length
26, while the Relay-reply produced by the kea server only includes a VSIO with
length 4. Let me know if you need any further information.
Thanks - Fred
[email protected]
> -----Original Message-----
> From: Wlodek Wencel [mailto:[email protected]]
> Sent: Monday, April 13, 2015 8:08 AM
> To: [email protected]
> Cc: Templin, Fred L
> Subject: Re: [kea-dev] RSOO bug in 0.9.1
>
> Hello,
> Thank you for your email. I checked again RSOO feature in Kea (sending
> Vendor-Specific Information Option with multiple sub-options, what I
> assume you do) and unfortunately I could not reproduce error you described.
>
> Can you provide more details? Like kea config file and capture from
> wireshark? Or details about Vendor-Specific Information Option you are
> including to message?
>
> Regards,
> Wlodek Wencel
>
> On 04/11/2015 12:44 AM, Templin, Fred L wrote:
> > Hello,
> >
> > I am trying to use the new RFC6422 Relay Supplied Options Option (RSOO)
> > facility.
> > My RFC6221 relay inserts a Vendor-Specific Information Option (option #17)
> > in the
> > Relay-forward message that will be sent to the kea server. The option has
> > length
> > 26 decimal. But, when the kea server does the RFC6422 transformation it
> > truncates
> > the VSIO to only include the option header and the 4-byte enterprise
> > number. The
> > VSIO is then inserted into the DHCPv6 Reply message, but loses the 22 bytes
> > that
> > follow the enterprise number.
> >
> > See attached for the kea log. It does not show anything about the
> > Relay-forward
> > or Relay-reply messages, but does show how the server inserts the VSIO with
> > length 4. Please let me know if any further information is needed.
> >
> > Fred Templin
> >
> >
> >
> > _______________________________________________
> > kea-dev mailing list
> > [email protected]
> > https://lists.isc.org/mailman/listinfo/kea-dev
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea.conf
Type: application/octet-stream
Size: 3672 bytes
Desc: kea.conf
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150414/5334a77c/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rsoo.txt
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150414/5334a77c/attachment-0001.txt>
------------------------------
Message: 3
Date: Wed, 15 Apr 2015 10:43:42 +0200
From: Marcin Siodelski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Statistics design proposal for 0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 14.04.2015 15:18, Tomek Mrugalski wrote:
> Hi all,
> One of the features planned for 0.9.2 are statistics. Here is the
> proposed design: http://kea.isc.org/wiki/StatsDesign.
>
> This design is not the most advanced or fully featured. It's a
> compromise between what we could do and what actually can do in the
> limited timeframe of 0.9.2 release.
>
> The basic concept is that the statistics are currently simple, but they
> can evolve over future releases. Whatever evolution path we'll choose,
> the API should remain stable, if possible.
>
> Please review and comment.
>
I would like to clarify the comment I have made at some point about the
use of concurrency when gathering the statistical information. I didn't
really mean that the statistics manager should run in a separate
process. I was rather thinking that it should run in a separate thread.
This thread could create a socket and listen on the fd belonging to this
socket. This would allow for better responsiveness of the stats manager
in the presence of many DHCP packets being received on possibly many
interfaces. This would also allow to perform certain independent tasks
like, reception of a command, unparsing JSON, creating and sending the
response concurrently with the main thread which handles DHCP stream.
There is a problem with the concurrent access to the StatsMgr such that
certain values have to be locked for write when second thread is reading
them. But, that is not something that can't be solved with the design of
the StatsMgr.
The stats manager's operation is going to be based on time intervals.
For example: keep statistics collected for the last 5 minutes. The use
of threads would probably make it much easier to use asio-based timers
which are asynchronous, i.e. based on callbacks invoked when specific
timers expire. You can't do it easily when you are hanging on the call
to select() in the main thread.
I take the point about the limited time for 0.9.2 but I am afraid we get
too much hammered to the idea of the synchronous processing even when we
could do better. I leave it up to you, but basically if I understand
correctly what Shawn said at some point, the lack of concurrency with
respect to statistics is the problem in isc-dhcp.
I wonder how statistics is going to be configured. I understand that
you're planning to add invocations to the StatsMgr in multiple places in
the code where you're going to bump the counters. But, is it going to be
possible to enable/disable specific counters so as they are not bumped
if not needed? Or, it is assumed that the counter bumping operation is
fast enough that such optimization would not bring a lot of benefit?
From the "Performance Optimization" section however it seems that it
has been of your concern.
I am iffy about the naming for statistics per subnet You say,
"subnet[0].packets-received". But, what if I remove the subnet with
index 0 from the configuration? The subnets will get renumbered and the
statistics will now apply to wrong subnet. Wouldn't it be better to
identify subnets using SubnetID which is supposed to be unique?
On the related note. Does this also account for the statistics per
interface?
In the data extraction section we should keep in mind that the
communication over the unix socket requires two sockets: one for the
client and one for the server. So I guess, you'll need to extend the
"control-socket" parameter to specify two names? I am also not so sure
that choosing the string as a parameter for control-socket configuration
is a right choice. If you want to use the same parameter for future
sockets: TCP, UDP or whatever else, it may quickly occur that you need
more parameters. If I am correct about the two names for socket files
you already have three parameters that describe the socket communication.
It would be useful if the design included some sample JSON requests and
responses, including responses which report errors in statistics
gathering. The organization of the JSON query and response should be a
subject for review because it will be troublesome to modify it once
people start implementing proprietary clients.
I also wonder if this "protocol" shouldn't be the base for the remote
management API, in which case we should take into account use cases for
the management API here? Not that I want to start implementing
management API right now, but just make sure that it will be compatible
when we implement it.
On the class diagram, I still think that it may be useful to make it
generic and allow for some additional types apart from the ones you
listed. In particular, string value. Suppose someone writes a hook and
wants to store some textual information in it like last error found.
Doesn't Observation require setValue modifiers?
Marcin
------------------------------
Message: 4
Date: Wed, 15 Apr 2015 13:46:58 +0200
From: Marcin Siodelski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Statistics design proposal for 0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 15.04.2015 10:43, Marcin Siodelski wrote:
>
>
> On 14.04.2015 15:18, Tomek Mrugalski wrote:
>> Hi all,
>> One of the features planned for 0.9.2 are statistics. Here is the
>> proposed design: http://kea.isc.org/wiki/StatsDesign.
>>
>> This design is not the most advanced or fully featured. It's a
>> compromise between what we could do and what actually can do in the
>> limited timeframe of 0.9.2 release.
>>
>> The basic concept is that the statistics are currently simple, but they
>> can evolve over future releases. Whatever evolution path we'll choose,
>> the API should remain stable, if possible.
>>
>> Please review and comment.
>>
>
> I would like to clarify the comment I have made at some point about the
> use of concurrency when gathering the statistical information. I didn't
> really mean that the statistics manager should run in a separate
> process. I was rather thinking that it should run in a separate thread.
> This thread could create a socket and listen on the fd belonging to this
> socket. This would allow for better responsiveness of the stats manager
> in the presence of many DHCP packets being received on possibly many
> interfaces. This would also allow to perform certain independent tasks
> like, reception of a command, unparsing JSON, creating and sending the
> response concurrently with the main thread which handles DHCP stream.
> There is a problem with the concurrent access to the StatsMgr such that
> certain values have to be locked for write when second thread is reading
> them. But, that is not something that can't be solved with the design of
> the StatsMgr.
>
> The stats manager's operation is going to be based on time intervals.
> For example: keep statistics collected for the last 5 minutes. The use
> of threads would probably make it much easier to use asio-based timers
> which are asynchronous, i.e. based on callbacks invoked when specific
> timers expire. You can't do it easily when you are hanging on the call
> to select() in the main thread.
>
> I take the point about the limited time for 0.9.2 but I am afraid we get
> too much hammered to the idea of the synchronous processing even when we
> could do better. I leave it up to you, but basically if I understand
> correctly what Shawn said at some point, the lack of concurrency with
> respect to statistics is the problem in isc-dhcp.
>
> I wonder how statistics is going to be configured. I understand that
> you're planning to add invocations to the StatsMgr in multiple places in
> the code where you're going to bump the counters. But, is it going to be
> possible to enable/disable specific counters so as they are not bumped
> if not needed? Or, it is assumed that the counter bumping operation is
> fast enough that such optimization would not bring a lot of benefit?
> From the "Performance Optimization" section however it seems that it
> has been of your concern.
>
> I am iffy about the naming for statistics per subnet You say,
> "subnet[0].packets-received". But, what if I remove the subnet with
> index 0 from the configuration? The subnets will get renumbered and the
> statistics will now apply to wrong subnet. Wouldn't it be better to
> identify subnets using SubnetID which is supposed to be unique?
>
> On the related note. Does this also account for the statistics per
> interface?
>
> In the data extraction section we should keep in mind that the
> communication over the unix socket requires two sockets: one for the
> client and one for the server. So I guess, you'll need to extend the
> "control-socket" parameter to specify two names? I am also not so sure
> that choosing the string as a parameter for control-socket configuration
> is a right choice. If you want to use the same parameter for future
> sockets: TCP, UDP or whatever else, it may quickly occur that you need
> more parameters. If I am correct about the two names for socket files
> you already have three parameters that describe the socket communication.
>
Forgive me my ignorance. Indeed you can use one file for the two-way
communication. But, still the point about making the configuration
parameter a map rather than string is valid. :-)
> It would be useful if the design included some sample JSON requests and
> responses, including responses which report errors in statistics
> gathering. The organization of the JSON query and response should be a
> subject for review because it will be troublesome to modify it once
> people start implementing proprietary clients.
>
> I also wonder if this "protocol" shouldn't be the base for the remote
> management API, in which case we should take into account use cases for
> the management API here? Not that I want to start implementing
> management API right now, but just make sure that it will be compatible
> when we implement it.
>
> On the class diagram, I still think that it may be useful to make it
> generic and allow for some additional types apart from the ones you
> listed. In particular, string value. Suppose someone writes a hook and
> wants to store some textual information in it like last error found.
>
> Doesn't Observation require setValue modifiers?
>
> Marcin
>
>
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 8
**************************************
