Network traffic shaping.

[Lior Vernia]

On 08/08/13 13:48, Giuseppe Vallarelli wrote:
> ----- Original Message -----
> | From: "Lior Vernia" <lvernia at redhat.com>
> | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | Cc: arch at ovirt.org
> | Sent: Monday, August 5, 2013 10:12:58 AM
> | Subject: Re: Network traffic shaping.
> | 
> | Hey Giuseppe and everyone else,
> 
> Hello Lior,
> 
> | 
> | Sorry for being late to the party. I've read all the e-mails and have
> | been rolling the idea around in my head for a couple of days. Here are
> | my two main thoughts, more UX-oriented, let me know what you think.
> | 
> | 1. I would prefer not to be able to create a host network QoS entity,
> | which doesn't really have any significance as an independent entity.
> | However, I would like to be able to copy the configuration from one host
> | to another for the same network, right? So how about we add a
> | "Copy/Clone from" UI field that lets you choose a host from which to
> | copy the QoS configuration for that network?
> | 
> | This would appear next to the manual configuration, so users would still
> | be able to input other custom values if they prefer. Once we do this, we
> | also won't need to enable to define it on a per-network basis, where it
> | doesn't really make sense, but we could do with just defining it for
> | <host,network> pairs (i.e. say in the edit network dialog when attaching
> | a network to a host NIC).
> 
> I like your idea and I think it's a good simplification overall.
> 
> | To further clarify, copying/cloning would be INSTEAD OF creating a
> | Network QoS through some subtab, naming it, and then picking it in a
> | list box. There would be no way to create a named host network QoS
> | configuration.
> 
> I thought it was the right approach simply because it's what have been implemented
> already in: http://www.ovirt.org/Features/Network_QoS
> (I'll refer to it as Network_QoS from now on)
> 
> I didn't want to have 2 different ways to create what I would call
> simply QoS (the infamous 6 values) that can be applied a host network,
> vnic and so on. That's where the idea of associating a predefined Qos
> comes from.
> 
> | 2. I would prefer to not have to fill six fields to define QoS. Even if
> | there are default values to these fields, it makes it look complicated.
> 
> I'm completely with you on this - libvirt only requires the average
> attribute, burst and peak are optional, but again for uniformity of
> behaviour with Network_QoS I opted to have all 6 user defined.
> Perhaps the uniform behaviour is misplaced in this case, I thought
> that it might be confusing for the user to provide 6 values in Network_Qos
> and only one, average, for QoS but host network side.
> 
> I discussed to have only one compulsory value in a different thread
> discussion "network and vnic qos" but Doron gave me a rationale (SLA related)
> for having all six values defined.

Yeah, I saw that discussion and I see Doron's point. I just wanna
clarify that all 6 values would still be set as per those comments - but
this assignment would be transparent to the users, unless they access
the "advanced settings" (still not sure how that should be accessed).

> 
> | I think these six values could be replaced by just one typical value for
> | the network's traffic. The six-field configuration would still be
> | accessible somehow, but I don't want it to be necessary.
> 
> +1
> 
> | 
> | Regarding the empty values discussion, I'm not saying to leave the
> | values empty. I get why we want to fill them. But fill them ourselves in
> | some reasonable way that users won't be aware of unless they go into
> | advanced settings.
> | 
> | An alternative might be to allow two values, one for inbound traffic and
> | another for outbound traffic. However, I think this would only be
> | necessary if a user wants to actually manage both inbound and outbound
> | traffic in detail, which sounds to me like the uncommon use case. In
> | general people would just want to avoid host traffic, either inbound or
> | outbound, being taken over by one network.
> 
> That's a good idea. My only concern is how does it fit with QoS in the
> engine as a whole ? It's almost like we have different definitions of QoS,
> which might be fine but maybe we want to find a different naming convention.
> 

I'm all for a different naming convention anyway, as we do not really
provide network QoS at the moment - networks are DC-wide entities and we
can't guarantee anything about what happens when packets leave the host.
I actually think "Host Traffic Shaping" is pretty good, I would maybe
call it "Host Traffic Control" because control is a simpler word to
fathom than shaping.

> 
> | And again, distinguishing
> | between inbound and outbound would still be accessible through some
> | advanced settings.
> | 
> | Lior.
> 
> Thanks for the contribute, hope my feedback will help.
> 
> Giuseppe
> 
> | 
> | On 08/07/13 13:45, Giuseppe Vallarelli wrote:
> | > Hi everybody, I'm working to implement traffic shaping at the network level
> | > [1].
> | > This feature is composed by two distinct parts: definition of traffic
> | > shaping
> | > for a logical network entity and optional redefinition of traffic shaping
> | > when
> | > the user is doing a Setup Host Networks task. Initial focus will be on
> | > first
> | > part. There are some points of contact with Network Qos [2] that's why I
> | > proposed
> | > to reuse some code backend side.
> | > 
> | > Cheers, Giuseppe
> | > 
> | > [1] http://www.ovirt.org/Features/Network_traffic_shaping
> | > [2] http://www.ovirt.org/Features/Network_QoS
> | > _______________________________________________
> | > Arch mailing list
> | > Arch at ovirt.org
> | > http://lists.ovirt.org/mailman/listinfo/arch
> | > 
> | 
>