On Apr 7, 2015, at 11:05 , Veiga, Anthony <anthony_ve...@cable.comcast.com<mailto:anthony_ve...@cable.comcast.com>> wrote:
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo <majop...@redhat.com<mailto:majop...@redhat.com>> wrote: Hi Anthony, nice to hear about it! :) Is the implementation available somewhere?, Yes, it’s been posted on github[1]. The URL would have helped. [1] https://github.com/netoisstools/neutron/ IMHO, the design should be what’s best for the whole neutron project looking into future extension of the design, by this I mean that we should not influence the design by what was already designed D/S, *but*, I’m sure there are lots of logic that we could reuse from the DSCP perspective, and even if API or internal implementation differs in the end, you’re going to get equivalent logic as soon as diffserv/DSCP is implemented. Absolutely. I’m by no means insinuating that what we have is the only way, or even the ‘right’ way. We had to do it for business requirements so we just got it done and are carrying patches. I’m definitely interested in Salvatore’s suggestion for starting with how to define things in the API first. Best regards, Miguel Ángel On 7/4/2015, at 15:07, Veiga, Anthony <anthony_ve...@cable.comcast.com<mailto:anthony_ve...@cable.comcast.com>> wrote: On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo <majop...@redhat.com<mailto:majop...@redhat.com>> wrote: I’d like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation & others [2] I’m very interested in seeing this feature mature. Sean was writing this code initialy while working with our team here at Comcast and we’re still carrying the patches he wrote through to new versions of Neutron. I’d very much like to discuss ways to bering them back into mailine. As per discussion we’ve had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], … I agree with starting simple. We’ve implemented basic DSCP marking only at this point to allow hardware switches to to queue and filter based on the marks. It would be great to bring the queueing down into the vSwitch and then extend this to things like minimum guaranteed bandwidth. I have a fair few applications that would benefit from these kinds of features. It’s the first time I’m trying to organize an openstack/neutron meeting, so, I don’t know what’s the best way to do it, or find the best timeslot. I guess interested people may have a saying, so I’ve looped anybody I know is interested in the CC of this mail. There’s no best way. Just pick an open meeting timeslot, email out the meeting details and get your notes/meeting minutes onto the wiki. Hopefully this works out and I’d be glad to help! -Anthony Miguel Ángel Ajo [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api [2] https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing [3] https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 [4] https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
