On 9 sep 2010, at 15:04, Rémi Després wrote: >> There is work going on on creating "multipath TCP" where a TCP flow is split >> into subflows which take different paths. (See the MPTCP wg.) Currently, it >> is assumed that the paths are defined by the source/destination address >> pairs, but there are many paths that can't be selected this way.
> Subflows of MPTCP have different 5-tuples. > They should be treated as different flows as far as load balancing is > concerned. That depends on the flavor of MPTCP. Certainly with the type of MPTCP that the wg of the same name is working on right now this is the case. But setting up a new subflow with new port numbers etc is rather involved as it involves both ends and needs security etc etc, while simply adopting a new flow label for a subflow can be done unilaterally by the sender. It would even be possible to create an MPTCP that doesn't change TCP semantics so only the sender is aware of the multiple paths and the receiver is an unmodified TCP receiver. Also note that for instance SCTP, which is also multipath, doesn't have port numbers. >> - we shouldn't lock down the flow label such that only one flow label per >> flow is allowed because this would impede future innovation > This shows the need to define what is meant by "flow" independently in EACH > context. That seems superfluous. Not everythig in life needs to be defined. > For load balancing, what is key is that: > - packets of a FL flow should be forwarded without changing their original > order (subject to best effort) > - packets of different FL flows may have their order freely modified within > the network. Note that there is no requirement that the network delivers packets in order. In fact, reordering used to be quite common. Of course we know that reordering is bad for performance, so indeed it is better that packets belonging to the same flow aren't reordered with respect to each other, while reordering of packets belonging to different flows is inconsequential. But that's common knowledge, I'm not sure how our discussion about the flow label impacts this (or the other way around). > If MPTCP people would have considered one "meta-flow" comprising several > "flows", there would have been little risk of confusion between MPTCP flows > and FL flows. > But the fact is that than they talk about one "flow" comprising several > "subflows". > Then an MPTCP subflow is a FL flow. You are splitting semantic hairs. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
