QoS Control at Runtime

[pchainho]

This issue is created to discuss the specification to enable QoS control of WebRTC peer connections used by Hyperties, by using the results from T3.3.

Specs to be provided here

[pchainho]

Having a short look on current specs it seems the QoS UA could be a simple service framework JS library that hyperties can use and not a core component of the runtime. Another possibility is to have the qos broker integrated with the MN and interactions between the runtime and the broker would be done through messages. it would have no dependency on the broker API and changes on the Broker API would have no impact in the runtime. Also the CSP could control the interface with the QoS Broker eg using the Policy Engine.

[sbecot]

I think maybe the second option would fit better. For the moment, the ice/turn candidates are written in the description.json which means that if the strategy changes it need a catalogue update, even if the hyperty doesn't change. This is probably more related to the MN strategy to use/not use stun, turn, or to use a broker. Then the candidates can be sent to the runtime.

[Endebert]

Some remarks from the LHCB side:

Interacting with the LHCB through a JS library is definitely feasible using a WebSocket interface. A simple WebSocket interface is already available for LHCB Clients, but for this scenario, a WebSocket Interface on the LHCB Broker side would have to be implemented.

[pchainho]

I'm missing input from LHCB in the specs in order to better analyse the full solution

[emmelmann-fokus]

All right, here is the overall picture that we plan to bring as well into the upcoming WP3 deliverable. Details will be handled in the dedicated QoS deliverable but it should provide an idea on the QoS interface available with the runtime.

We will provide a library (LHCB Library) that interacts via web sockets with the LHCB clients (i.e., interface i1 in the picture).

i1 will be used to a) retrieve information about last hop links local to the client, i.e., the local interfaces b) retrieve a globally unique LHCB Client ID (which is needed to identify QoS / link information about the client, here Client A, within the LHCB Broker c) retrieve the Public IP address of the LHCB broker (which will be needed later to enable other clients to retrieve information about remote clients)

i2 will be an interface between two running hyperties, i.e., it reflects a direct hypertey-to-hyperty communication. Communication is established by the same means as for (e.g.) the hello world example. These means are out of scope of the LHCB-specific interface enhancements. Once established, i2 will be used to a) retrieve the LHCB Client ID and Public IP Address of the LHCB Broker handling that client

i3 is a web-socket based interface to allow the Client to retrieve the public IP used by the Broker.

i4 will be used to retrieve information about last hops at remote clients. Requests sent from, e.g., Client B to the LHCB Broker to retrieve information about Client A need to contain the LHCB Client id of Client A and need to be directed to the Public IP of the LHCB Broker handling Client A. Such information may be retrieved via i2.

i5 is only mentioned for completeness; it reflects the existing COAP-interface between Client and Broker.

@Endebert will continue to work based on that architecture, especially he will provide this week some flow charts that illustrate my summary of functionality of the interfaces.

We will then proceed to work on a first (preliminary) interface spec for i1 and i2 for the upcoming deliverable; noting that the final fixed spec will be included in the dedicated QoS deliverable.

[pchainho]

Couple of quick comments / questions:

• it is difficult to understand how the LHCB fits together with Orange TURN based solution
• is the LHCB client external to Web Runtime? Is it a component to be installed in the device?

[emmelmann-fokus]

it is difficult to understand how the LHCB fits together with Orange TURN based solution

It provides information on last hop link QoS that can be retrieved by TURN services and taken into consideration when choosing network paths; it may be used to request to switch to an alternative last hop connection (e.g. from LTE to WiFi and vice versa) if the other link has preferable QoS parameters.

is the LHCB client external to Web Runtime? Is it a component to be installed in the device?

Yes and yes.

The Fokus of the WP-3 deliverable is to give a rough idea about the interface as accessible from hyperties etc. We need to avoid to include content of the dedicated QoS deliverable now as it weakens the other deliverable. But one sentence as above should add clarification and be suitable.

[emmelmann-fokus]

All done. Added text ready for integration in the deliverable at:

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/qos/readme.md

and

https://github.com/reTHINK-project/specs/blob/master/qos/readme.md

@pchainho thanks for your patience. Let me know if you run into issues migrating the figures into Word.

[pchainho]

I reopen this issue to clarify how to progress in terms of implementation.

[emmelmann-fokus]

Implementation has beed deferred per decision of WP / project leadership during the face-to-face meeting in Lisbon. This is due to the required prioritization of #13

[sbecot]

Concerning integration of the QoS finally I think my previous answer is not good. Indeed, integration of the Phase 1 implementation shouldn't take place in the runtime, but directly in the Connector Hyperty. Indeed, the QoS is enforced via Turn relay and DSCP marking which is related with the WebRTC layer.

[emmelmann-fokus]

Implementation of LHCB library done to allow hyperties to interact with LHCB client and with other hyperties. Interfaces specified in D3.4

[emmelmann-fokus]

closing. deliverables are out.