[iccrg] TCP-in-UDP next steps and clarification

[Michael Welzl <[e-mail]>]

[as author of draft-welzl-irtf-iccrg-tcp-in-udp, not chair ]

Dear all,

Thanks for your feedback on the list so far and the feedback in the meeting!

Here’s one explanation I wanted to give: someone, I think Matthew Sargent, commented that something similar could be done with MPTCP, by using multiple subflows between two hosts each having only one network interface.
My answer was a little vague - I said that the congestion control coupling is pretty similar but not quite, yet I didn’t explain the (rather subtle, but important) differences. These exist because MPTCP’s coupling assumes that flows *can* (actually should) take a different path. Some things that we can do with TCP coupling would probably be inappropriate there - at least MPTCP’s coupling doesn’t do them:
- a new connection joining the aggregate can immediately get a share of a potentially quite large cwnd of ongoing transfers. This can significantly reduce the completion time of short flows but in MPTCP it would be like using a very large initial window on a new path
- to do this, we influence slow start: as I said in my presentation, we only enter slow start if *all* connections enter slow start. This includes new ones: if a connection is already in congestion avoidance, it immediately means congestion avoidance for everyone.
- we also assign a cwnd share based on a priority. These can even change on the fly. Again, if connections would traverse different paths, this behavior is probably quite inappropriate, and MPTCP’s coupled CC wouldn’t do that.

Of course, MPTCP’s subflows also use different tuples in order to get different paths (almost the opposite of what we want). But that’s just the encapsulation - my point is, even if we’d use our own encapsulation, the MPTCP coupled congestion control doesn’t work for us. Yes, there are similarities, the goals are partially similar, but not entirely and so there are some quite significant differences too.

BTW someone also asked me if this could be used for connections in a VPN instead of using our UDP encapsulation. I say yes, absolutely.

Cheers,
Michael