Subject: [multipathtcp] Comments on draft-ietf-mptcp-congestion

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 29 Jul 2010 10:41:51 +0200

Dear all,

here are some comments on draft-ietf-mptcp-congestion, based on my
implementation experiences. I send it to the list, in order to save time
during today's session.

- The draft is already very helpful as it is, but it requires IMHO
substantial further extensions.

- It is really good that the draft distinguishes between byte- and
packet-based stacks (section 4.1). However, the short part on
packet-based congestion windows is not always clear to me, in particular
concerning a potential consideration of the MSS (which is, BTW, not
constant for option encoding, but that's not my point here). For an
implementor, it would be better to have a full specification of the
algorithm for packet-based stacks, too.

- As noted in the draft, updating the parameter alpha on every
congestion window update would result in a huge overhead. If it is done
more seldomly, it might be interesting to somehow average the input
parameters for that formula. Yet, it is not entirely clear if this
should be done, and how. A somehow tricky problem is the special
handling of fast retransmits. It would help if the draft provided more
guidance on an infrequent calculation of alpha.

- In general, some of the most interesting use cases of multipath
transport include high-speed links with larger RTTs. In this case, users
of MPTCP would suffer a performance penalty when using a coupled
congestion control algorithm based on Reno, compared to the widely used
high-speed alternatives. I think that it would be really interesting if
the draft gave some high-level comments how congestion control coupling
could be used for a high-speed congestion control variant, e. g.,
RFC3649, or a delay-based algorithm.
Maybe this could be a short, informal appendix.

- The draft could probably motivate why congestion window coupling is
actually needed as long as the number of subflows is smaller than the
limit ("REC-3") given in draft-ietf-ledbat-practices-recommendations.

I am sorry if I should have misunderstood something. Also, I can't
comment on the actual suitability of the algorithm right now, given that
I have not well tested its operation so far.

Thanks

Michael

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 29 Jul 2010 11:02:36 +0200

Hi,

Thank you very much for your review. We will take into account all the missing things you've identified for the next revision of the draft.

> Maybe this could be a short, informal appendix.

Sure. This is just a multipath equivalent of standard TCP CC. Extending this work to use delay signals too (like Compound TCP) seems quite straightforward, but we haven't done the work so we don't know the details yet. Using other algorithms as a basis is also possible (i.e. Cubic), but is again work that needs to be done. We will include a note in the draft.

> limit ("REC-3") given in draft-ietf-ledbat-practices-recommendations.

The coupling mainly moves traffic away from congestion. The RTT compensation is the one that deals with the TCP fairness issue - I guess you are saying we could be more aggressive when the number of subflows is small. If that's acceptable, its trivial to update the algorithm.

Thanks,
Costin