CoNEXT'16 Session 3: Transport and end-to-end

1. PI2: A Linearized AQM for both Classic and Scalable TCP

Author: Koen De Schepper (Bell Labs Nokia), Olga Bondarenko (Simula Research Laboratory), Ing-Jyh Tsang (Bell Labs Nokia), and Bob Briscoe (Simula Research Laboratory)

Presenter: Koen De Schepper

Koen started the presentation by explaining some of the key features of Data Center TCP (DCTCP) like consistently low queueing delay, full link utilization with small queue, vey low loss, more stable throughputs, scalable, available in windows 10, linux 3.18. Yet to be optimized (for high RTTs at least). Unfortunately, we can’t use DCTCP in current internet as it starves the classic TCP-friendly flows, keeps big tail drop queues full, needs ECN (so high loss or fallback to Reno). Till now, this model is used in Data Center as everything can be changed at once without relaying on the consistency of other components.

They found two key challenges while solving this problem. First, how to make DCTCP and TCP-Reno rate compatible and the second one is to preserve low latency for DCTCP. This paper is all about how they tackled the first challenge as the second one is their future work (namely Dual-PI²)

Next he explained why any AQM will work with an equal drop probability for each flow. Comparing Classic TCP with DCTCP-Step and DCTCP-Slope, he stated that DCTCP marks On-Off marking rather having the similar slope in TCP- Reno or Cubic. Since, AQMs for steady state test results doesn’t give reasonable drop probability, this offers equal window for steady state.

Later recapping PI-AQM briefly, he dived into the paper itself. According to them, by omitting the square-root from congestion control and putting a scalable p instead can get rid of many complex calculations. In the end, he explained why high probability means less responsiveness of the system.

In short, newly proposed PI² is simpler than PIE. It performs not worse and supports scalable congestion control (by removing the the square from the output). PI controls natively scalable CCs, so, adaption function is needed to convert any CC to a scalable. So, combination of PI and PI² can support both scalable and classic CCs. Finally, he concluded the presentation with the link for this projects.

https://github.com/olgabo/dualpi2

http://riteproject.eu/dctth

Q. In DC, TCP problem is solved. What are the next?

A. This is actually a way to migrate from something which is the past and legacy and couldn’t have been changed. We know there are better solution which are not being used yet like DCTCP; that we can’t use in today’s internet. So, this is kind of way to define new mechanism which scales and has lot more advantages and one obstacle is the migration process. Once, every TCP in internet will be replaced by DCTCP, we can remove the dual-queue from the step.

This is certainly only one migration. Hopefully in future, TCP congestion control and other research will be done to find out the best solutions.

Q. Are you ever going to run-off between PI² and Single FQ-CoDel?

A. Yes. What we are trying to achieve here is the same that can be done by FQ-CoDel. We are trying to add fair share between the flows and actually without inspecting the transport headers. We don’t need to the flow, we just need to know per packet, whether it’s a DCTCP or not. This is more E2E solution and less complex, but probably not as optimal and perfect at network level as CoDel.

Q. Compare results for PIE and PI². PI² has lower peaks, so probability actually reduces. So, it’s less aggressive in some sense then the PIE who has couple of higher peaks. Any intuition, why?

A. It is not actually less aggressive control. Because by tuning it, based on certain probability, alpha and beta factors are scaled up or down and thus gives more or less the same effect.  

2. SMig: Stream Migration Extension for HTTP/2 (short)

Author: Xianghang Mi (Indiana University), Feng Qian (Indiana University), and Xiaofeng Wang (Indiana University)

Presenter: Xianghang Mi

HTTP/1.1 is the widely adopted protocol for internet for a while. Since the emergence of HTTP/2 in 2015, it offers some interesting features like header compression, multiplexing schemes, server push capability that enables servers to push directly to the client. Xianghang orchestrated a scenario where, server responding for a large file download while client requests for a small file simultaneously, the performance degrades dramatically. So, he explained how the new features of HTTP/2 motivated them to use this protocol to resolve this and some other problems in their proposal.

           

Head-of-the-Line-Bottleneck is pretty common in real world. Stream prioritization or starting a completely separate connection doesn’t help resolving HoLB problem. According to Xianghang, migrating an on-going stream from one connection to a complete separate stream in HTTP/2 can be a solution.

Then, he Introduces with a new frame (Migration frame) and couple of flags to ensure correct cross-connection ordering of frames. To discuss the design of SMig, he explained 4 migration scenarios,

1. Initiated by server w/ idle conn
2. Initiated by client w/ idle conn
3. Initiated by server w/o idle conn
4. Initiated by client w/o idle conn

 As design consideration, he explained how SMig strategically manages idle connection. He also covered the implementation of SMig and their experimental setup as well. Finally, to evaluate their method, he showed the four strategies they explored, which are:

1. NoMig: large file is multiplexed into smaller.
2. MigSW: server initiates the migration for large file once it receives request.
3. MigSP: Server initiates the migration, but only a small part is being migrated.
4. MigCP: Client initiates the migration, but only a small part is migrated as a request.

This was short paper, so he referred to the paper for details and concluded the presentation with summarizing their work.

Q. Who will schedule which file to move to another connection? (In test scenario, this scheduling is done manually) Integration of SMig with DASH solution to provide more elegant and optimal for CDN solution?

A. Yes, for testing, we migrated the traffic manually. In fact, which side will be responsible for migration is a policy decision. Who will initiate or what policy should they use is yet to be explored. For instance, in 3^rd scenario (server initiated migration), 100 kb was the threshold, but for rea scenario, what would be the threshold. 

A. Not yet considered. May be later.

Q. Is any special application needed for using this solution?

A. I don’t think so. This feature can be implemented as the client or server library. Applications can call directly the library functions (for socket or use API) to use migration.

3. MP-DASH: Adaptive Video Streaming Over Preference-Aware Multipath

Author: Bo Han (AT&T Labs -- Research), Feng Qian (Indiana University), Lusheng Ji (AT&T Labs -- Research), and Vijay Gopalakrishnan (AT&T Labs -- Research)

Presenter: Bo Han

(This paper was one of the best paper award recipient in CoNEXT ’16.)

Bo Han began his presentation with explaining some of the exciting features of MPTCP as it splits single flow over multiple physical path, offers more speed and mobility. But, the best feature of this protocol is its transparency (in socket layer).

Now-a-days, video is the main contributor of mobile traffic. According to CISCO, 50% of entire mobile traffic is video and is predicted to rise up to 70% by 2020. Despite DASH, QoE is still un-answered. Open WiFi can’t provide best performance though it is available in almost everywhere. So, the question comes, can MPTCP help to achieve better performance?

It is well-known, MPTCP offers robust solution. However, the challenges and opportunities for MPTC need exploring. Bo Han and his team did an experiment in a controlled environment where they streamed with ~ 4 Mbps (with WiFi 3.8 Mbps as well as LTE 3.0 Mbps bandwidth). Key observation from this experiment was LTE capacity was fully utilized (only 0.2 Mbps needed).

The main goal of this project was to create an interface preference aware MPTCP for adaptive streaming. (assuming WiFi is preferable to LTE). To do so, they tried to leverage delay tolerance of DASH streaming to tweak MPTCP scheduling. Key component would be the deadline- aware MPTCP scheduler.

Next he moved on explaining MPTCP architecture. One important thing to note here is server doesn’t know the next churn to be requested. So, add intelligence of how to control cellular sub-flow was a solution. When enabling cellular, utilize the max b/w by transmitting as quickly as possible. MP-DASH introduces both deadline-awareness and link-priority into MPTCP.

Next, he introduced us with MP-DASH adapter and its main challenges. Since, different cross-layer interaction with MP-DASH has already been implemented, adaptation logic (throughput vs buffer based) was one of the key challenges for them. Another challenge was designing its control loop. So, the basic approach consists of either chunk size or chunk deadline (duration based or rate-based).

To make a prototype for this, they have used a ~300 lines of code as a portable patch of MPTCP on linux kernel. MP-DASH adapter was based on open-source GPAC player. There are 4 DASH rate adaptation: GPAC, FESTIVE, BBA and improved BBA. For evaluating MP-DASH, they’ve used 2 evaluation tool, namely MP-DASH scheduler and MP-DASH framework.

Bo Han et al have used MP-DASH in 10 different locations, dividing them into 3 categories (WiFi only can never support high quality video i.e., hotel or food market, WiFi can sometime support but not always i.e., airport or coffee house, WiFi can always stably support i.e., library). The key question here is what if we don’t use LTE in this location at all?

He also explained MP-DASH usage under Mobility scenario with their experimental setup. The key take-away from this are

• MP-DASH adaptively uses cellular only when WiFi throughput drops
• Vanilla MPTCP drives cellular to full capacity, regardless of WiFi throughput

 In conclusion, Bo Han summarizes the deployment of MP-DASH that is based on upgrading MPTCP and DASH rate adaptation. He mentioned some limitation of their setup such as use of a laptop instead of an actual mobile. Finally, he shared their future plans of using MP-DASH for general application like music app using recommendation, delay-tolerant mobile data offloading to find out more benefits of MP-DASH.

Q. Really cool stuff. I am curious about the choice of metrics? You focus on radio energy consumption and throughput. Why not buffering, bit rate switching? Do you have someway to normalize these QoE metrics across all the players? What was the buffering size ratio between MP-DASH vs regular DASH?

A. This is a very good question. This is called other metrics. For current evaluation, most of the time the aggregated throughput of WiFi and cellular is coding bitrate of DASH radio. So we focus on cellular data usage and radio energy consumption. In future we plan to evaluate MPTCP with bit rate and with other QoE.

Q. I think, first question already answers my question. But, I am interested to see some more QoE for evaluation. How often the bit rate is changed or what jumps the change of bitrate?

A. We have evaluated MPTCP and identified the changes of bitrate. We found that most of the cases, MP-DASH will not affect the QoE, it can maintain the same encoded bitrate as Vanilla MPTCP.

Q. Can you use any standard metrics for bitrate changing?

A. We haven’t done that. We can do that in future.

Q. The adaptation is based on some estimation of delivered packet bitrate. Why not using a simple predictor which is exponentially weighted, rather using more complicated one?

A. We did some literature survey and according to 2005 sigcomm paper, Holt-Winters predictor performs much better in TCP.

Q. In this context?

A. In general.

Q. When you’re saying you’re reducing the utilization of cellular network by 80% or 90%, what problem are you trying to solve? Are you aggregating bandwidth or trying to improve the reliability by shifting between WiFi and cellular?

A. MPTCP always try to utilize the full capacity of underlying link. But, sometimes, user may prefer to use WiFi over LTE. So, for a scenario, where MP-DASH can use only 0.2 Mbps of LTE to support the highest bitrate of the video, but Vanilla MPTCP can’t do that.

Q. What was the RTT difference between the cellular network and WiFi you worked on?

A. We run experiment in different locations. So, by default, MPTCP prefers the link with higher RTT. If the demand of an application is higher, MPTCP decides to use the second sub-flow which will always try to utilize the full capacity. As long as there is space in TCP window, it will send packets to the secondary link.

So, dead-line aware MP-DASH scheduler is an overlay on top of the original MPTCP scheduler. It’s not a completely new MPTCP scheduler.

Q. Video quality depends on how accurately you can predict. So, for dash, using throughput makes it more credible or less?

A. MPTCP has nothing to do with the loss of packet accuracy as MPTCP is just a set of inspections of regular TCP.