IETF Logo Mail Archive

Re: [multipathtcp] MPTCP Schedulers

Christoph Paasch <cpaasch@apple.com> Fri, 15 February 2019 18:07 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B71274D0 for <multipathtcp@ietfa.amsl.com>; Fri, 15 Feb 2019 10:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZlIPWgei2re for <multipathtcp@ietfa.amsl.com>; Fri, 15 Feb 2019 10:07:34 -0800 (PST)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C37130FC5 for <multipathtcp@ietf.org>; Fri, 15 Feb 2019 10:07:34 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x1FI6QGi037243; Fri, 15 Feb 2019 10:07:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=ii1gpVDSZyzcXhFW5pq1U1I0DJ33FqlrreKZ8qjyyC0=; b=uC8/6ZJDj40nOSb9MjzJcFy/pfPTuaqpxemvs5whodWkYYYCCjhX4XbtVog8ci0/PE12 7Hma0JzRgFKium/T3AYy67goyY65SaJdjoe5+ZorUUKozHlGDQCxV9d3NHuE2Ny89aEe sYfwaHZ5rJrvQcSD0dh38lUjpO3r2707USLPJxkH0Uy47pFariHAMauMqKgZBs52u1o0 aKtLDdYWvnhILy0d3toubwuXAW9BjRVOI39jONrSojwezchIPMGOKUZzNKzYBpQxLTy+ rzxHc1MEUdvBTKEwdOFmnew38aCbMUQhEiDoUZh9FSpoN+28CIxONlbe1B33tr2jKY0X rA==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2qhxpatrrf-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Feb 2019 10:07:26 -0800
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PMZ003I1BOA4V70@ma1-mtap-s02.corp.apple.com>; Fri, 15 Feb 2019 10:07:23 -0800 (PST)
Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PMZ00E00BEYR400@nwk-mmpp-sz10.apple.com>; Fri, 15 Feb 2019 10:07:23 -0800 (PST)
X-Va-A:
X-Va-T-CD: ce9af30ef0380078f11a5893c97260d3
X-Va-E-CD: 60632c09d938b75503323bd9642dc634
X-Va-R-CD: 5a313c0d1e1c416600cf69e8a77233a6
X-Va-CD: 0
X-Va-ID: 2f4f5510-e2e9-423f-8bf4-0a189b17867e
X-V-A:
X-V-T-CD: ce9af30ef0380078f11a5893c97260d3
X-V-E-CD: 60632c09d938b75503323bd9642dc634
X-V-R-CD: 5a313c0d1e1c416600cf69e8a77233a6
X-V-CD: 0
X-V-ID: 9f8f30ac-3f5f-427c-adea-bb2a7eb5e1fb
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PMZ00200B3JBS00@nwk-mmpp-sz10.apple.com>; Fri, 15 Feb 2019 10:07:22 -0800 (PST)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-15_13:,, signatures=0
Received: from localhost ([17.192.155.217]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PMZ00BAABOA7Y10@nwk-mmpp-sz10.apple.com>; Fri, 15 Feb 2019 10:07:22 -0800 (PST)
Sender: cpaasch@apple.com
Date: Fri, 15 Feb 2019 10:07:22 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>
Cc: multipathtcp <multipathtcp@ietf.org>
Message-id: <20190215180722.GR1880@MacBook-Pro-19.local>
References: <a939bc37-16ed-9d8a-15d7-16dfec630290@cs.pub.ro>
In-reply-to: <a939bc37-16ed-9d8a-15d7-16dfec630290@cs.pub.ro>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-15_13:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/OyVTL6zizEejJNqqMaiPcYQQYRQ>
Subject: Re: [multipathtcp] MPTCP Schedulers
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 15 Feb 2019 18:07:37 -0000

On 15/02/19 - 15:42:55, Vladimir Olteanu wrote:
> Hi guys,
> 
> I'm trying to tie up any loose ends in the SOCKS 6 draft. There is some
> functionality which lets you change the MPTCP scheduler used by the proxy.
> The available schedulers are basically the ones available in the Linux
> kernel implementation.
> (https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-05#page-20)
> 
> Do you think it would be worthwhile to standardize the MPTCP schedulers? I
> think an informational or best practice RFC would be useful.

In general, I think that would be good. The tricky part around MPTCP is that
the client has no direct control on the server's scheduling behavior.
The backup-bit provides some amount of control but it's not fine-grained enough.

Standardizing the schedulers or providing a more explicit "API/messaging"
from the client to the server about the client's policies would be very
useful.

That way, clients can connect to "any" MPTCP-server and make sure that the
server's behavior is respecting the client's policies about data-usage on
the different subflows.


Christoph

> 
> Cheers,
> 
> Vlad
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

v2.23.0 | Report a Bug | By Email