Network traffic shaping.

[Doron Fediuck]

----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: "Giuseppe Vallarelli" <gvallare at redhat.com>
> Cc: arch at ovirt.org
> Sent: Thursday, August 8, 2013 2:19:41 PM
> Subject: Re: Network traffic shaping.
> 
> 
> 
> 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.
> 

Actually this feature provides an upper limit which enables QoS, by
preventing starvation. So QoS is definitely relevant here.
With regards to traffic * name, this implies on implementation,
while QoS may be set by other means (such as defining it in the
network device). So I still keep my original definition that this
should be host level network QoS.


> > 
> > | 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
> > | > 
> > | 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>