[ixpmanager] [RELEASE] V5.5.0 - Member Port Utilisation Reporting

[Rob Lister]

Thanks Barry -

We have some members that just repeatedly have very short spikes in 
traffic on an otherwise
underutilised port, for example you'll see some sort of sync or backup 
take place in the
middle of the night when they don't care about their port being loaded 
for a short time,
then it returns to normal.

They consider this just to be normal traffic rather than anything 
anomalous.

We would only really want to contact those members who are persistently 
running their ports.
very hot.

Perhaps a compromise might be some ability to acknowledge or make a note 
against individual
overloads so they show up in some other colour. "This will always happen 
every day at 5am. They don't care."

Flatlining is another behaviour which should be flagged up regardless of 
the physical interface
capacity, for example if they are on a resold port, or are limited to 1 
or 2G on a 10G port,
or some backhaul capacity in their network can't deliver enough traffic 
to their IXP port,
then it'll flatline at a lower rate. The solution to this problem isn't 
always that we need to
sell them another port, but perhaps capacity needs to be increased 
somewhere else.

I'll open a feature request when I get a few minutes.


Rob



On 2020-04-07 15:34, Barry O'Donovan wrote:
> Hey Rob,
> 
> 
> Rob Lister wrote on 23/03/2020 14:34:
>> This is a much needed feature - thanks for implementing it at this
>> time.
> 
> Cheers :-)
> 
>> A couple of thoughts come to our minds, if you update this in a
>> future release:-
>> 
>> 1. Would be more useful to have the option to calculate it to 95th 
>> percentile to avoid it flagging up temporary traffic spikes.
> 
> Separate to what Nick said on this, I'm uneasy about implementing 95th
> percentile here. If a port is exceeding a level of utilisation that
> triggers the IXP to start the discussion on upgrading then I don't see
> that it matters if it's at 95th or not. As IX's we're interested in
> ensuring packets aren't dropped and they will be dropped whether the
> cause is spikes or normal usage.
> 
>> 2. VLAN column seems redundant since at the top, it filters by VLAN 
>> already.
> 
> We have >1 peering LAN so it has use for us and others like us. Not
> sure if I'm missing your point...
> 
>> 3. A way to filter out certain ports, for example Netflix and some
>> other CDNs have the ability to max out a port without congestion
>> since they have tight software controls on what gets delivered where.
>> (customer flag or a field like the "Active Peering Matrix" to exclude
>> some members.)
> 
> If such a CDN has a 100Gb port and is flatlining (albeit without
> dropping packets) then I still want to know because there's pent up
> traffic demand there.
> 
> That said, I do also see a use for what you're suggesting and I've had
> something similar in mind so I'll see what I can do here. Best thing
> to do here Ron - if you're interested in seeing this happen and track
> it - is to open a feature request on Github. We'll probably get there
> anyway but it may move it along :-)
> 
>  - Barry

-- 
Rob Lister
rob at lonap.net
+44 20 3137 8330