Re: [multipathtcp] how to deal with GRO when we use MPTCP?

Joe Touch <touch@isi.edu> Wed, 22 March 2017 15:42 UTC

Return-Path: <touch@isi.edu>
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 A491F1299D5 for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 08:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 l-uIoNG-AqQF for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 08:42:44 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 431FB1299DE for <multipathtcp@ietf.org>; Wed, 22 Mar 2017 08:42:44 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2MFg6Wc028464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Mar 2017 08:42:07 -0700 (PDT)
To: Olivier.Bonaventure@uclouvain.be, =?UTF-8?B?546L5biF?= <13211134@bjtu.edu.cn>, multipathtcp <multipathtcp@ietf.org>
References: <2e5562a3.3efcf.15af4ee489c.Coremail.13211134@bjtu.edu.cn> <d81b7cf0-67ff-9a2b-31ee-63c44fbe7643@uclouvain.be>
From: Joe Touch <touch@isi.edu>
Message-ID: <77ee43ab-cab9-586b-b40e-e53fb0bb9a47@isi.edu>
Date: Wed, 22 Mar 2017 08:42:05 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <d81b7cf0-67ff-9a2b-31ee-63c44fbe7643@uclouvain.be>
Content-Type: multipart/alternative; boundary="------------C1837304602704B115098D73"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/wWWEB6SnmRlspVzF69X1gouc5F8>
Subject: Re: [multipathtcp] how to deal with GRO when we use MPTCP?
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: Wed, 22 Mar 2017 15:42:54 -0000

FYI - we had experience with GRO on Linux where it acted against spec,
coalescing packets with EDO headers even when these options were
different between adjacent packets. We also saw performance plummet when
GRO was enabled even when it was not supposed to coalesce packets.

See Sec 5.2 of the following:

H. Trieu, J. Touch, T. Faber, “Implementation of the TCP Extended Data
Offset Option <http://www.isi.edu/touch/pubs/isi-tr-2015-696.pdf>,”
USC/ISI Tech. Report ISI-TR-696, Mar. 2015.

Note that we were unable to pinpoint the issue, which might have been in
our implementation.

Joe


On 3/22/2017 1:54 AM, Olivier Bonaventure wrote:
> ...
>
> GRO should not coalesce packets from an MPTCP sender that does not use
> TSO and thus send packets with different DSN values. If you see a
> network interface that behaves badly, please report this on the
> mptcp-dev mailing list
>
>
> Olivier
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp