Subject: [iccrg] review of draft-barik-mptcp-lisa-01

From: Joe Touch <[email-masked]>
Date: Wed, 16 Nov 2016 01:27:07 -0800

Some feedback on this document.

Overall, I think the issue is important and useful to address. II don't
know if this should be in ICCRG or MPTCP, though.

Leaving that issue aside, some notes below. Note that this is not a
TSV-ART review, but rather my individual review.

Joe

-----

My primary concern is when this issue arises and whether MPTCP addresses other cases. E.g., LISA appears to focus on the impact of new flows on existing flows (and on the new flows themselves), which is very similar to RFC 2140 (this might be useful to note in the intro). In fact, the algorithms here are being considered in the pending revision to RFC 2140 in TCPM.

In particular, wouldn't similar issues arise during slow start restart? If all flows restart at the same time, there might be unnecessary competition. I'm not familiar enough with the MPTCP algs to know whether this is already addressed. Similarly, the situation might arise when flows disappear (e.g., interfaces go down, paths are impeded) or if some flows experience slow start restart but others do not (is that even possible in MPTCP?).

The text regarding the applicability might need to be updated. 2140 has its greatest impact on new flows when those flows are intermediate - not too long or too short. Connections that are very short might not impact other flows (they might not even send the full initial window). Connections that are too long are dominated by steady-state effects rather than the initialization effects (where 2140 is limited). However, *all* longer flows are impacted by the start and stop of other flows and 2140 sharing should help them converge more quickly regardless of whether new connections (flows) are added or removed. 

As a result, I think it might be useful to explain that the real issue being addressed by any such sharing is a *change* in number of concurrent flows.

---

---

From: Michael Welzl <[email-masked]>
Date: Sat, 19 Nov 2016 21:41:45 +0900

Hi Joe,

Thank you very much for taking the time to read this, and sorry for the delay of my answer -  in line:

> On Nov 16, 2016, at 6:27 PM, Joe Touch <[email-masked]> wrote:
> 

The reason to go to ICCRG was that the MPTCP charter doesn’t currently allow for congestion control updates. The decision (between ICCRG and MPTCP chairs, announced on both lists) was to work on it in ICCRG for now, and if the charter will accommodate congestion control in the future, go back to MPTCP, else aim for publication via ICCRG.

> My primary concern is when this issue arises and whether MPTCP addresses other cases. E.g., LISA appears to focus on the impact of new flows on existing flows (and on the new flows themselves), whi…

Indeed; in MPTCP the situation is a bit more problematic though - e.g. the aggressive behavior in slow start explicitly goes against goal 2 laid out in RFC 6356 (“Do no harm”).

> In particular, wouldn't similar issues arise during slow start restart? If all flows restart at the same time, there might be unnecessary competition. I'm not familiar enough with the MPTCP algs to…

Good question, I’m not sure this is possible - I would guess not. We’ll try to look into this. Generally the problem tackled here occurs whenever one or more flows start while one or more other flows already are in slow start. However, it’s about the effect of no_subflow * IW + slow start on the wire; in restart we’d have RW=1, not IW which may be 10.

> The text regarding the applicability might need to be updated. 2140 has its greatest impact on new flows when those flows are intermediate - not too long or too short. Connections that are very sho…

True - we need at least 3 rounds before we even seen the problem that LISA fixes.

> As a result, I think it might be useful to explain that the real issue being addressed by any such sharing is a *change* in number of concurrent flows.

Okay yes - indeed that is the case being addressed, we’ll try to make this clearer in the text.

Thanks again, this was very helpful!
Michael