[multipathtcp] thoughts on compatibility mode

William Herrin <bill@herrin.us> Mon, 09 November 2009 15:29 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=HpoWP86d0t+ZHKgIa+ziFWHx/Rdf4HKgccsm4evRk0OUMpP1hfskfCPjgDYwsYhZtB ytinVW+mB0CKI2Mxe8SK9S88G2V/GQSLilUTN8FHKDTzxuHF63ECfV3+BEyRLqGqzxZ0 FYWXJbjh6sWiAwspUqOv/lD7CEGtIYxOE5exM=
MIME-Version: 1.0
Sender: wherrin@gmail.com
Date: Mon, 09 Nov 2009 10:29:35 -0500
Message-ID: <3c3e3fca0911090729x6cc32fcds4e656bc677a4856c@mail.gmail.com>
From: William Herrin <bill@herrin.us>
To: multipathtcp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [multipathtcp] thoughts on compatibility mode
Precedence: list

Hi folks,

Some thoughts on compatibility mode and the API for legacy apps that
aren't aware of multipath TCP:

Should probably pick a default behavior but punt the final decision to
the operator. He's the one in a position to know for sure whether
multipath will work OK for a particular system or application.

Should probably have a system default and allow it to be overridden by
an environment variable that the API checks during a socket() call.

MULTIPATHTCP=DISABLED
MULTIPATHTCP=ENABLED
MULTIPATHTCP=COMPATIBILE
MULTIPATHTCP=COMPATIBILETRY
MULTIPATHTCP=COMPATIBILELIE

DISABLED - multipath TCP will not be used, even by applications which
are built to the new API.

ENABLED - multipath TCP will be used by the apps which are built to
the new API. Legacy apps will not attempt multipath TCP.

COMPATIBLE - all PF_INET and PF_INET6 TCP sockets (legacy apps) are
also eligible to use multipath TCP, although binding a specific local
address will implicitly disable it. The API uses the multipath
semantics, so getsockname() and getpeername() return EMULTIPATH and
accept() does not return an IP address in the sockaddr structure.

COMPATIBILETRY - all PF_INET and PF_INET6 TCP sockets are eligible.
accept(), getsockname() and getpeername() will return the address of
the oldest active subflow whose semantics are compatible with the
socket's declared address domain. If there are no such subflows,
COMPATIBILETRY will act like COMPATIBILELIE.

COMPATIBILELIE - all PF_INET and PF_INET6 TCP sockets are eligible.
accept(), getsockname() and getpeername() will return a non-routeable
IANA-assigned address whose meaning is defined as "you asked a
question multipath TCP can't reliably answer."  Then when folks query
google for why "255.255.255.1" shows up in their logs, they'll get a
bunch of documents about multipath TCP and legacy servers.

Regardless of the environment variable setting, apps built to the new
API will use the new API semantics.


Comments? Criticisms?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

[multipathtcp] thoughts on compatibility mode William Herrin