Re: [multipathtcp] The point about multiple listening sockets at theclient side

Yuri Ismailov <yuri@ismailov.eu> Thu, 12 November 2009 04:22 UTC

Return-Path: <yuri@ismailov.eu>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D2228C1EC for <multipathtcp@core3.amsl.com>; Wed, 11 Nov 2009 20:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUFsyiNRYz9R for <multipathtcp@core3.amsl.com>; Wed, 11 Nov 2009 20:22:47 -0800 (PST)
Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 0E53428C1ED for <multipathtcp@ietf.org>; Wed, 11 Nov 2009 20:22:47 -0800 (PST)
Received: from [133.93.19.5] (host-19-5.meeting.ietf.org [133.93.19.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id E2136576AA4; Thu, 12 Nov 2009 05:23:13 +0100 (CET)
Message-ID: <4AFB8DAC.1030008@ismailov.eu>
Date: Thu, 12 Nov 2009 05:23:08 +0100
From: Yuri Ismailov <yuri@ismailov.eu>
User-Agent: Thunderbird 2.0.0.23 (X11/20091002)
MIME-Version: 1.0
To: William Herrin <bill@herrin.us>
References: <4AF8B8A5.4040602@ismailov.eu> <2181C5F19DD0254692452BFF3EAF1D6808D7BB53@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911101220g55f84f79nf62526d8693d39fa@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808D7BDEE@rsys005a.comm.ad.roke.co.uk> <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com>
In-Reply-To: <3c3e3fca0911111737t5c783bf7rb96f49bb15f360e3@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] The point about multiple listening sockets at theclient side
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 12 Nov 2009 04:22:48 -0000

William Herrin wrote:
> On Tue, Nov 10, 2009 at 8:07 PM, Ford, Alan <alan.ford@roke.co.uk> wrote:
>   
>>> On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan <alan.ford@roke.co.uk>
>>>       
>> wrote:
>>     
>>> 2. When the acceptor tries to add a subflow, he best not offer a syn.
>>> The syn won't get through the initiator's firewall. Nor should it: a
>>> SYN packet to a non-multipath host would be interpreted as a plain
>>> connection attempt.
>>>       
>> Disagree. Well, I can see what you're saying, but subflows /need/ to be
>> SYN+SYN/ACKed, whichever way they go, since they are essentially
>> standard TCP sessions, reassembled at the endpoints. In particular,
>> although there may be some firewalls that would let that traffic
>> through, many others would not (not part of a known TCP session), not to
>> mention other middleboxes anywhere along the path, including many NATs,
>> that would not know what to do with TCP packets that do not appear to be
>> part of a session they know about (since they haven't seen a SYN for
>> that particular 5-tuple).
>>     
>
> Hi Alan,
>
> Plot the middlebox use scenarios:
>
> TS: TCP SYN-SYN/ACK-ACK from the server to the client which includes
> the multipath TCP subflow join option.
>
> MJ: TCP packet without SYN but containing the multipath TCP join
> option and expecting the same sort of JOIN-JOIN/ACK-ACK handshake.
>
> Scenarios:
>
> No firewall: TS succeeds. MJ succeeds.
> Packet filter: TS fails. SYN to a random client port? Don't think so!
> MJ succeeds.
> Legacy Stateful firewall: TS fails. MJ fails.
> Legacy "DSL router": TS fails. MJ fails.
> Multipath-aware stateful firewall: TS fails. SYN to a random client
> port? Bad plan! MJ succeeds.
> Multipath-aware "DSL router": TS fails. SYN to a random client port?
> Come on! MJ succeeds.
>
> Or am I missing something?
>
> Regards,
> Bill Herrin
>
>
>   
Hi,
As it looks like a client should be initiator at all times in order to
provide a smooth operation.
Would it be reasonable to send some options or needed information in the
join flow from server to client, so that the client would start
SYN-SYNACK-ACK exchange?
Regards
Yuri