Network traffic shaping.

Thu Aug 8 10:48:17 UTC 2013

----- 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.

| 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.

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
| > 
| 