Comment 2 for bug 1727578

Thanks YAMAMOTO,
Yeah, just outgoing traffic.

For ServiceConnection, I think it is the same thing, Service Connection is about site connection for current VPNaaS reference implementation.

For VPN qos is very useful for real Datacenter, as the whole traffic will running based on the physical network. I had initial 2 ways for this feature.

1. Apply Neutron qos policy on the router interface port directly, but the ease-west traffic would be affected by this policy if there are other interface attached on the same router. So I think a use case about this, for the real usage of VPN, the user's VM will contain routes like:
VM IP:10.0.0.33

default via 10.0.0.1 (to access east-west or external network)
10.20.0.0 via 10.0.0.3 (to peer_vpn_cidr from other site.)

So I think this way is the right direction from some situation.

If the vm just contains a default route or we don't want to inject some necessary routes into vm, we can easy to set a route into the Router which its subnet gateway locates on. The route may like "10.20.0.0 via 10.0.0.3" either. The function works.

2. Use linux kernel to process the specific traffic and apply QoS with 'tc' command, in Router namespace, the external port 'qg-XXX'. The tc rule should be set like:
tc qdisc del dev qg-XXX root 2>/dev/null
tc qdisc add dev qg-XXX root handle 10: htb default 2254
tc class add dev qg-XXX parent 10: classid 10:1 htb rate 64kbps ceil 64kbps

And if we want more granularity like only some IPs on this subnet will be limited by the QoS. We could add 'tc' rule with iptables. But this way we may need to intro a new API for defining the QoS rule looks like, and it will have a strong-bonding relationship with l3 implementation.

Thanks, yamamoto. Wish you feedback. :)