Well, if you can figure out some way to make it interface properly with the cake code (successor to fq_codel), I'm all for it.
http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical On Wed, Oct 14, 2015 at 4:00 PM, Maxim Klyus <[email protected]> wrote: > Dear Netmod, Homenet and MIF. > > > > We are looking for a proper place to discuss attached materials within IETF. > > So I would like to say sorry we have to send this letter across several IETF > WGs simultaneously. > > > > The latest trends show that IP services are getting decoupled from the > traditional Service Provider (SP) networks. Subscriber can get a lot of > services from the 3rd party content providers typically delivered over > public networks, P2P services are also becoming more and more popular and > the main problem how to achieve service chaining and delivery with proper > QoS. > > We would like to propose to use Yang for exchange between Subscriber’s > Device and Service Provider’s. The Yang-modeled data is transferred over > NetConf protocol from end-user device activation/management software towards > a service agent software residing in Subscriber’s Device. This approach > allows Service Provider to identify subscriber uniquely and his QoS > requirements within the network with multiple IP interfaces on Subscriber’s > Devices. Multiple IP interfaces will be used for service distinction and > delivery within SP network. Host applications will be divided by application > groups and bounded to a specific IP interface. > > > > Short solution description: > > > > 1) When connecting to the network, Subscriber’s Device gets an IP address > through DHCP and IP of SP’s headend device management server through a DHCP > option. Alternative option is manual configuration of these IP settings; > Service Agent Software installed on Subscriber’s Device makes AAA request to > Service Provider’s configuration management headend software. Based on > request SP can uniquely identify subscriber and subscriber’s QoS > requirements. In case Device was authorized successfully, it gets a new IP > interface (Tunnel or Loopback) and additional configuration parameters > (e.g., routing, QoS). SP network also will be reconfigured dynamically to > meet appropriate service delivery KPIs , however static SP environment > configuration also possible with fixed QoS and bandwidth for each interface > based on predefined IP pool. > > > > 2) Different application groups can originate service requests from > different Host IP addresses. Service will be delivered to specific IP > addresses with appropriate additional handling within SP network and quality > of service. Subscriber’s device can periodically send application-group QoS > modification requests to allocate more/less priority or/and bandwidth for > existing application groups within SP network. > > > > Benefits and Applicability: > > > > - SP don’t need to know anything about external services > located outside their network (Internet services, 3rd party content > providers). Service identification will be based on local Service Provider > IP addresses. > > > > - QoS configuration will be delivered dynamically based on > subscriber needs. > > > > - SP don’t need to make any dramatic updates for existing > environment to identify services, because traffic identification and > handling will be based on IP stack only. > > > > > > P.S. Authors are looking forward to developing this approach further. The > authors have already tested the approach using manual settings > > Potential next steps include: > > - developing a Host Agent prototype; > > - developing a Headend's NETCONF/YANG adapter; > > - collaboration with a carrier to arrange a lab trial; > > - contributing the code to the open source community. > > > > If you have any kind of questions please feel free to contact us directly > [email protected], [email protected] > > > > Best Regards, > > Maxim Klyus > > > > > > ________________________________ > The information transmitted herein is intended only for the person or entity > to which it is addressed and may contain confidential, proprietary and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht Do you want faster, better, wifi? https://www.patreon.com/dtaht _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
