Network Data Monitoring

Streif, Rudolf rstreif at jaguarlandrover.com
Mon Sep 12 20:11:03 EDT 2016


Hi Gunnar,


I’ve been meaning to answer this email but some other things apparently came
> in between :-)  This thread is a big top-posting, HTML-based extravaganza
> so I’ll follow suit.  Apologies to the newly added people that need to read
> in reverse. :-)
>
> Ok, I'll end the top-posting a little and hack my responses into your
text. :)

I keep the HTML-based extravaganza as this is what GMail does. I does work
best inside a browser.



> Assuming that monitoring includes “accounting” (a term that could be used
> to
> mean the measurement of how much bandwidth is being used, on a
> per-application
> basis) I therefore reach out to Daniel Wagner and Marcel (on CC) to see if
> he has
> continued working in this domain after the topic was discussed on LPC a
> few years
> ago [1], or is interested in some new speaking partners.
>
> It think it mostly means "accounting" as a means to control bandwidth
usage, QoS, routing etc.


> I was there in person and remember “everyone” seemingly identifying the
> same
> problem, including Automotive and other embedded GNU/Linux, and Android
> representatives.
>
> I would agree that this is of importance for many other applications. If
anybody knows of any activities in this area, I would like to learn about
them. There is no point in reinventing the wheel (no pun intended, although
that's what our industry thrives on).


> There were already some ideas presented but none that Daniel was 100% happy
> with.
>

Daniel is Swiss and only the network monitoring/accounting equivalent of a
Swiss army knife will do: versatility, accuracy and precision. :)


>
> I would imagine integration with the known (and GENIVI specification
> required)
> components like ConnMan (isn’t that what you mean instead of oFono below?)
> might have even progressed since then (sorry I have not kept up).
>
> ConnMan is certainly a good place to integrate such a thing. I don't know
of that type of functionality in ConnMan either. Marcel/Daniel?


> While RVI is definitely solving a lot of use cases, I would think that
> *some*
> network connections that do not use RVI will still remain in the system,
> and that
> solutions for monitoring, accounting and policy enforcement are likely
> needed on a more fundamental level of the Linux stack, and decoupled from
> RVI.
>
> Fair enough. I don't necessarily want to push it as far down the stack as
the kernel but I think ConnMan is a reasonable place.


> It would be good to pick this up and continue working on it together.
>
> How about during the Networking EG f2f at the AMM in Burlingame?



> For the extremely short on time, Daniel's detailed solution proposals
> start at 6.30,
> but Marcel’s introduction before that is important introduction. [1]
>
> @Daniel - perhaps you already have a rudimentary requirement specification
> that could
> fit Rudi's request?  I’ll ping some networking guys in VCC also to see if
> they want to add
> something to the thread.
>
>
Please forward anything to me you have. I appreciate it.

Thanks,
Rudi


> Best Regards
> - Gunnar
> [1] https://www.youtube.com/watch?v=ulIqVzsC03g
>
>
> Original email:
>
> >From: genivi-projects-bounces at lists.genivi.org [mailto:genivi-projects-
> bounces at lists.genivi.org] On Behalf Of Feuer, Magnus
> >Sent: den 26 maj 2016 00:51
> >To: Jeremiah Foster
> >Cc: eg-nw at mail.genivi.org; genivi-projects at lists.genivi.org
> >Subject: Re: Network Data Monitoring
> >
> >Hmm.
> >
> >RVI has full SMS support (3GPP 27.005) and integrates with pppd to manage
> 2G / 3G / LTE data links. We also have netlink integration to monitor when
> data links (ppp0, wlan0, etc) become available or disappear.
> >
> >What we do not have (yet) is data usage monitoring. This should be fairly
> straight forward to build as a part of the data link interface where the
> low-level protocol codec does the byte counting.
> >
> >Ulf: Your opinion.
> >
> >Rudi: Do you think you can put together a simple req spec so that we at
> least know the main features we want to cover?
> >
> >/Magnus F.
> >
> >
> >-------------------
> >Head System Architect - Open Source Projects
> >Jaguar Land Rover
> >
> >Email: mfeuer1 at jaguarlandrover.com
> >Mobile: +1 949 294 7871
> >
> >
> >Jaguar Land Rover North America, LLC
> >1419 NW 14th Ave, Portland, OR 97209
> >-------------------
> >Business Details:
> >Jaguar Land Rover Limited
> >Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
> >Registered in England No: 1672070
> >
> >This e-mail and any attachments contain confidential information for a
> specific individual and purpose.  The information is private and privileged
> and intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient, please e-mail us immediately.  We
> apologise for any inconvenience caused but you are hereby notified that any
> disclosure, copying or distribution or the taking of any action in reliance
> on the information contained herein is strictly prohibited.
> >
> >This e-mail does not constitute an order for goods or services unless
> accompanied by an official purchase order.
> >
> >On Wed, May 25, 2016 at 1:24 PM, Jeremiah Foster <
> jeremiah.foster at pelagicore.com> wrote:
> >
> >
> >On Wed, May 25, 2016 at 10:22 PM, Streif, Rudolf <
> rstreif at jaguarlandrover.com> wrote:
> >Include, genivi-projects mailing list, as it seems there is no eg-rvi
> mailing list.
> >
> >If you need an rvi specific mailing list that can of course be created.
> >
> >Cheers,
> >
> >Jeremiah
> >
> >On Wed, May 25, 2016 at 12:38 PM, Streif, Rudolf <
> rstreif at jaguarlandrover.com> wrote:
> >Colleagues:
> >
> >One of the components in the responsibility of the NW EG is monitoring of
> data network traffic and usage.
> >
> >The original plan for this component was to create extensions to oFono
> and possible the Linux IP stack for that purpose. After an initial effort
> this has stalled. There are also a couple of implications with an
> integration of such an infrastructure into upstream components.
> >
> >Since RVI now is becoming the universal data transmission framework from
> and to the vehicle platform, it makes sense to revisit that topic within
> the new context.
> >
> >My initial questions are:
> >1.     Are there any current plans for RVI to provide such facilities? If
> so what are they and what requirements have been identified? (There are
> currently no requirements defined by the NW EG.)
> >2.     Would we want to proceed with it? What urgency do we see.
> >Thanks,
> >Rudi
> >
> >
> >--
> >Rudolf J Streif
> >System Architect - Open Source Initiative
> >Open Source Technology Centre
> >
> >M: +1.619.631.5383
> >Email:  rstreif at jaguarlandrover.com
> >
>
>


-- 
*Rudolf J Streif*
System Architect - Open Source Initiative
Open Source Technology Centre

*M:* +1.619.631.5383
*Email:*  rstreif at jaguarlandrover.com



UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
US: 1419 NW 14th Ave, Portland, OR 97209
jaguar.com | landrover.com
-------------------
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a
specific individual and purpose.  The information is private and privileged
and intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient, please e-mail us immediately.  We
apologise for any inconvenience caused but you are hereby notified that any
disclosure, copying or distribution or the taking of any action in reliance
on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless
accompanied by an official purchase order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160912/5e9f140c/attachment.html>


More information about the genivi-projects mailing list