[multipathtcp] Fwd: MPTCP Performance in Data Centers

imed eddine Bezahaf <ibezahaf@gmail.com> Tue, 28 March 2017 07:30 UTC

Return-Path: <ibezahaf@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 97AE6129413 for <multipathtcp@ietfa.amsl.com>; Tue, 28 Mar 2017 00:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2ldShnZjnHN8 for <multipathtcp@ietfa.amsl.com>; Tue, 28 Mar 2017 00:30:07 -0700 (PDT)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B77A126C7A for <multipathtcp@ietf.org>; Tue, 28 Mar 2017 00:30:07 -0700 (PDT)
Received: by mail-ot0-x232.google.com with SMTP id 102so36286374otv.0 for <multipathtcp@ietf.org>; Tue, 28 Mar 2017 00:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YbxNi+vXW+LaZG2dBrCoX7ilFXzrK/6VHzg18Wm9MKU=; b=QBRK9IjtwYRB1EhYX8Gfrde4EhDIMMV/eR5G1LRTKwRk31DjS30tGnql5nBWcVlqLL GMCfM+Flos2Ow2goq6snWy6WwW7O3UaeN/OIIzZ547eN09NUcg3MyOuIKzplLxkXj7TH Rp+Qn4ReNTsdVLrfMxb+hcVSZj3kIw1IIhnWeYICjshameFnFuo3BLAyO3XA7TSdIZm9 it24i/Pfe4I2WL2l2hruGkNQsTQaRT0XEf5IemuamF9Hjugvv/YdX3BBkjtY+XyQJ6/s ss37lfksuChqtPKwsmEmQQAnsaQaec+qJfWCwX76d6GcYJOr6FuROVkAEwIis0IW15L9 FVMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YbxNi+vXW+LaZG2dBrCoX7ilFXzrK/6VHzg18Wm9MKU=; b=SS2t/q8+8FIwZ+G3SVO92LtI0IfdsyFs3QC7TDjTkGabMM/IZ9fYi7Aib0jpEar8QY PwstlhG96ozWRo2WqOhPX4RMSjRuchgcqCGunskA8h+oYKaSLl2fqEqAUVoYftaOcW+O DBQoJbKsVE4cc27YAU0x97qfrTWDL0/8TrRhwX1wkFSXxqBa9NtMF874ujaZP7AaxTDe K6VJCCNBXwcexdLGFru+/tkgJznL6xd6dwfdGIXsEiJRNiy9opxIZg8Uj59VROYGqRRj TZcY3DuaqW4owmmAizOVvQ2b1ZPAFwO/0wKd5AbtT+gCG4/DZyEylvJNG1G/OvOxjbWG Zp8w==
X-Gm-Message-State: AFeK/H0pf3Addlr7yQRSBx3Uink4khCxJAXXoGVpXQCkvKbt5SfxeecWCZPKYGYO7voIIMb3+uI7535A2+rEuw==
X-Received: by with SMTP id f52mr3241777otd.117.1490686206106; Tue, 28 Mar 2017 00:30:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 00:30:05 -0700 (PDT)
In-Reply-To: <CAM5m8ouHc2jbL0xrN5cF4PZmRfRmcc2O5vHtZnt3wd+S5iYiiQ@mail.gmail.com>
References: <CAM5m8ovwvBtgoP6bVgdEaYb50zdCbRw+NrGUpDpjHCuC_X-bng@mail.gmail.com> <CAM5m8ouHc2jbL0xrN5cF4PZmRfRmcc2O5vHtZnt3wd+S5iYiiQ@mail.gmail.com>
From: imed eddine Bezahaf <ibezahaf@gmail.com>
Date: Tue, 28 Mar 2017 09:30:05 +0200
Message-ID: <CAM5m8ovORZhS3f+Sm4EvmNM6wtc5-uBWAP+8JBBvia2fZtri7A@mail.gmail.com>
To: multipathtcp@ietf.org
Content-Type: multipart/mixed; boundary=001a11492656ca51d8054bc56d14
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/xgHMFy-tzzB16OJBHlCdlSGrXaw>
X-Mailman-Approved-At: Tue, 28 Mar 2017 08:25:20 -0700
Subject: [multipathtcp] Fwd: MPTCP Performance in Data Centers
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 07:30:10 -0000


I am conducting a master thesis that has the following purpose: "To improve
MPTCP performances in data centers  by orchestrating  path assignment for
MPTCP flows(subflows) using SDN(Openflow)".

During my thesis I have noticed that even though I assign subflows to paths
where the throughput for every MPTCP flow should be fair (disjointing
subflows belonging to the same flow passing through the same path and make
sure that every link contain the same number of subflows), some flows might
actually achieve higher throughput than others. So my question is how fair
is the sharing of bandwidth among MPTCP subflows and not standard TCP
steams since in my thesis I assume that all the servers in the datacenter
support fully MPTCP.

I tried to look for an answer by searching in current works and paper
however I did not really find an explanation. Because all works related to
MPTCP and fairness are actually comparing throughput of MPTCP flows with
TCP streams (non-aggressive) in shared bottlenecks but never a comparison
between MPTCP flows only.

So I did an evaluation using mininet which is a network emulator to emulate
a 4 ary FatTree network but each host has 2 interfaces, so instead of
having 16 hosts, I have 8 hosts (with two interfaces). (Figure_1)

The traffic pattern is as follow:
H1 -> H8  (Two flows ): H1 sends two simultaneous MPTCP flows towards H8
H2 -> H7  (Two flows ): H2 sends two simultaneous MPTCP flows towards H7
H3 -> H6  (Two flows ): H3 sends two simultaneous MPTCP flows towards H6
H4 -> H5  (Two flows ): H4 sends two simultaneous MPTCP flows towards H5

So each pair of hosts open two MPTCP transmissions (all of them
simultaneously). In other words, 8 flows start at the same time.

Note: each flow has 4 subflows (I also tried with two subflows, it is a
little bit "fair" than 4 subflows but it follows the same curve)

Path characteristics: all links of the fattree have the same delay(100
microseconds) and the bandwidth is 5 Mbps.

I plotted a graph where you have in the y axis a normalized throughput (1
means a flow have achieved 10 Mbps (since two interfaces and each link has
5 Mbps)) and in the x axis, all the flows (8) ranked by order. Figure 2.

So my questions are:
Is this fair? half of the flows have between  (50%-60%) and half (40%-50%)
even though I am making sure that every subflow share the same number of
flows along its path. Figure3 shows a specific communication between H4-H5
(MPTCP 2 subflows) to give you an idea about how paths are assigned.
Note: I tested this with CUBIC, BALIA, OLIA, LIA, WVEGAS, all bring out
this same result.

Note: the flow size is identical for each one and it is 10 Mbytes and as I
mentioned previously the bandwidth of every link is 5 Mbps.

I would be very grateful and appreciative if you can help me out understand
this behavior or explain this graph if it is possible of course.

Thank you again,