Re: [multipathtcp] High-level design decisions /architecture

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mark Handley wrote:
> 2009/11/3 Joe Touch <[e-mail]>:
>> Costin Raiciu wrote:
>>> Hi Joe,
>>>
>>> The proposed congestion controller gives the aggregate multipath
>>> connection the throughput a TCP would get on the best (fastest) of the
>>> paths available (to the multipath connection). It does so only by
>>> looking at loss rates and rtts on the different paths. It does not need
>>> to know whether there is a shared bottleneck or not.
>> If it doesn't, then you will create the potential for a single multipath
>> group to fight with itself, which seems less than productive.
> 
> Well, so long as the total window increase per RTT of all the subflows
> in a connection is no more than a single vanilla TCP would get, then
> you don't fight with yourself any more than one TCP would ("fighting"
> in this context is pretty much equivalent to how much unacked traffic
> per RTT a flow can inject - the ack-clocked traffic already had its
> space last RTT, so isn't "fighting" for extra space).

Fighting could occur if the subflows send packets at the same time, even
if the aggregate is the same as a single TCP would have sent. A single
TCP never sends two packets out at once (it serializes them), but
separate TCPs could easily do this (even if the OS serializes them, they
could go out simultaneously from different NICs).

Keeping in mind how TCPs like to sync, this sounds like an area to keep
an eye on.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrwoBUACgkQE5f5cImnZruozQCggmyOhsWNSxiX+kUOvJCRSyDD
cJYAnigSjqBrnI8rDcDMy8lbtYadMJxW
=4YMs
-----END PGP SIGNATURE-----