IETF Logo Mail Archive

Re: [multipathtcp] Regarding the release of sending buffer

Vincent Stone <shihang7422166@gmail.com> Thu, 10 August 2017 08:46 UTC

Return-Path: <shihang7422166@gmail.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 A0EB613265D for <multipathtcp@ietfa.amsl.com>; Thu, 10 Aug 2017 01:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1uTeKUiyxl7B for <multipathtcp@ietfa.amsl.com>; Thu, 10 Aug 2017 01:46:42 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 8323413265B for <multipathtcp@ietf.org>; Thu, 10 Aug 2017 01:46:42 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id o86so515019pfj.1 for <multipathtcp@ietf.org>; Thu, 10 Aug 2017 01:46:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Az7WDYHgUzHl1E176454Z4QGAQO1+tccRHBOvPoI94=; b=ldzwueiwElpHsHR4pXcch5JpuNxgBhwOHcySuX3OjwsMnt5pcbKG/cvHO+zLeqP46F mgV3/9XRrzCCHTbwkouCreczC2Q7uJU8lk3MZkdfWqegB3Gl8XkBR7S2DDphvFwDgFqM VK/Y5LxmPrbzV1w85D7Vxu3BUYtZDROLyaC2gOlhdYCf1WcKWf67QFlSUdgBJY0rxtbt UTyzOS0G7vQlmBniytE95Wyl2jILgRH3KEvJZoLITl210/hleyA6aBrR3eU8j+PWOsE/ zD/9wVu5QiGrodRBo/TbKJL7xcsj/3C+PChOqbWjBKmRCRMxZlHqkk4/9EzUjjxpKEGJ lXsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Az7WDYHgUzHl1E176454Z4QGAQO1+tccRHBOvPoI94=; b=HrIaI/pNHKECINZTPGyLJBpavmHQJUH91ZlKf9J3g3dcSpCRYDQ5KK82WbQET4NT2g 0PLHp33socV9xxkBzTf5+jTLbnxh+fqh+0ZRs85qeJ4nqJ0ZDjh1yEjhGPOpN8qmOYVt b/Nxt9JNYWXXam+129/kn+6ye/v+0SUznrI7YcHesv4TZ8P37GfPyhnIQHTZn0j5W73F C0RRS9+EgZuFml8gN3pYyXXAOfLMTJRsTxHvKcwLMjabcYebHQZzO5wX250JHWARyZOe bZxGoLiw0PKPe3EeeqoRCoVEe5hUn8tpdAvCS0DUX0IFZDuOpA5pcYCS199tV/mfq6EL D6zQ==
X-Gm-Message-State: AHYfb5gEOEqktwz0GCmpWdr/lzwusIw4a7IgqKEuXjOaR4sw/K2B2uxD eZisIU3x4a2fSQ==
X-Received: by 10.84.229.6 with SMTP id b6mr12490916plk.274.1502354801958; Thu, 10 Aug 2017 01:46:41 -0700 (PDT)
Received: from [127.0.0.1] (107.182.176.120.16clouds.com. [107.182.176.120]) by smtp.gmail.com with ESMTPSA id e5sm11500194pgn.55.2017.08.10.01.46.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:46:41 -0700 (PDT)
From: Vincent Stone <shihang7422166@gmail.com>
Message-Id: <05010808-D254-4630-A49C-84F21CAA8175@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_17E05D57-506D-4CE3-AB31-D4F9FE533ABB"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 10 Aug 2017 16:42:18 +0800
In-Reply-To: <20170809034815.GX3648@Chimay.local>
Cc: multipathtcp@ietf.org
To: Christoph Paasch <cpaasch@apple.com>
References: <0940F5BC-7405-4AB0-9C73-E125B56F66B2@gmail.com> <20170809034815.GX3648@Chimay.local>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/-EnprKgUita_Cg2Jc2_5PNtD0-E>
Subject: Re: [multipathtcp] Regarding the release of sending buffer
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: Thu, 10 Aug 2017 08:46:43 -0000

Thanks for your response. Let us say we take the preventing retransmission approach. Can the middlebox/firewall notice that? 
There is only 1 scenario in which the middlebox will deem the data should be retransmitted( keep in mind that the data has already been delivered correctly to the receiver because it has already been acknowleged by Data ACK): 
all following ACKs after the data has been lost/dropped(Just dropped single ACK for the data is not enough because of accumulative ACK). In that case the flow should be terminated anyway. 
In fact, there is no way in which a middlebox can distinguish between sender don't retransmit the packet and the retransmitted packet has been lost. So I think it is safe to prevent the retransmission, thus we can free the data upon receiving Data ACK safely.

Best regards,
Vincent

> On Aug 9, 2017, at 11:48, Christoph Paasch <cpaasch@apple.com <mailto:cpaasch@apple.com>> wrote:
> 
> 't look like "regular" TCP anymore.
> 
> Middleboxes and firewalls will start blocking this traffic and the receiver
> must also be able to gracefully handle this.
> 
> That's the reason why MPTCP tries hard to make every subflow look like it is
> regular TCP, besides a few TCP-options.

v2.23.0 | Report a Bug | By Email