Re: [multipathtcp] Regarding the release of sending buffer

Vincent Stone <shihang7422166@gmail.com> Thu, 10 August 2017 08:47 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 551CF12706D for <multipathtcp@ietfa.amsl.com>; Thu, 10 Aug 2017 01:47:47 -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 am2zblv_YNkd for <multipathtcp@ietfa.amsl.com>; Thu, 10 Aug 2017 01:47:45 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 0F407126E3A for <multipathtcp@ietf.org>; Thu, 10 Aug 2017 01:47:45 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id v77so401216pgb.3 for <multipathtcp@ietf.org>; Thu, 10 Aug 2017 01:47:45 -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=C0zXIT5hwkHcbU+nxh4cCWDHAoFLPAsKaeqRUoXhtMY=; b=C5busoetcnzZ1Fp2Kjwb6ged8RKAx7fDtaz7G5TS3wV8B3JxJMiE39Ptzr4Ws9lEG7 4rRFnrctaN8p43yUkPcWc6hzgQSkvwQdgoaAX1/VTPQPcq6287ZX/azvQSRZWfpVE7Lt wpk16967nBp8f+WVWQIEcZEDuNb+kR/4/OA6PXBowzjo9289SDJ8ypuuehp4oF4Vv9lT Nv4xWMxQfakjlbRd6gbzf1rMn4r05Gf+LVOgMPaF1DBmps2c78z/an5aiVDkSIyO0dEN qZ/CkovDLRIUeWkQf2A27CodWy0oD8pnQbyRnvZa1BDM4m7Tt//CBpnhXuPRmrFAY0Ey DTWg==
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=C0zXIT5hwkHcbU+nxh4cCWDHAoFLPAsKaeqRUoXhtMY=; b=K4KRgm6KYxgNl61PeIqMo/bIimfw8DUyLXvl8C10YL1gjwq4WAW59rjJddpvWHhD7t GGXO4bX8c3W3GbAS7bQhe9iAfItqqIMj7tI5CQvm7CkqA0Jujmp88A6qqiX/qdqASnki Kt4tjAvDJ9kzEc3pMEZntow1YAjU+xwGu3nhS9D+J5+SH/5LapKzgARsbRsOhyyhj4Cs pC2mWESKSsGRQGhTns2IGZq9DLLe4X7yjHxGwjLjtQRzTd9qT0zKmaFIQuMB7g3G/WQ6 yW0qJHNW7uoJ0qu4kArZ9Nl/L8i2picggWxZdx+ztTRZuCC/QM3JLgO1PVe5kz9qpJr9 xB1A==
X-Gm-Message-State: AHYfb5j6HuApjOTR0lV7HOHGw34tXpWyT3dW+8nTwvzJYB/DPplbb5MH 4VoYhvSIFQjOqg==
X-Received: by 10.98.212.92 with SMTP id u28mr11186197pfl.316.1502354864440; Thu, 10 Aug 2017 01:47:44 -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 84sm9283106pgd.48.2017.08.10.01.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:47:43 -0700 (PDT)
From: Vincent Stone <shihang7422166@gmail.com>
Message-Id: <DEE60ED0-9BBA-4713-B5BF-6E48D73ECC71@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC04B9C3-2E5B-4F4D-9C8F-D4FB969DD9F2"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 10 Aug 2017 16:47:41 +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/ZD4bCjG0nzQ7AbWnXlBGRSDRHzs>
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:47:47 -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.