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

["Ford, Alan" <[e-mail]>]

Hi Bill, all,

> On Mon, Nov 9, 2009 at 8:06 PM, Ford, Alan <[e-mail]>
wrote:
> > The client (in terms of software) does not need to open listening
> > sockets in this case. But the MPTCP stack itself will be listening
on
> > all interfaces for potential incoming subflows from the server,
which
> > when initiated are joined to the existing connection. The
application
> > does not need to do anything for this to happen (but if an extended
API
> > were in use it could, for example, have callbacks to be informed).
> 
> Hi Alan,
> 
> Two thoughts:
> 
> 1. When the initiator (of the overall connection) tries to add a
> subflow, he'll want to use the same destination port number and a full
> syn-syn/ack-ack handshake to maximize the chances of getting through
> the acceptor's firewall unscathed.

Agreed - and not to upset port-based traffic engineering either.

> 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).

Regards,
Alan