Subject: On Thursday's Multipath TCP BOF

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Jul 2009 22:58:54 +0200

Dear all -

Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I
would like to express my support for this effort by email.

Multipath TCP promises to enable an attractive set of new features --
ranging from automatic fail-over, to load-balancing, to mobility
support.  Even though there are, of course, important challenges to be
surmounted, early analyses indicate the feasibility of the concept as
such.  And the strong academic background and support from key IETF
folks ensures that people with clue and sufficient time will work on it.

Therefore, personally, I believe this BOF should be given a thumbs-up
for working group establishment.

- Christian

---

From: Fred Baker <[email-masked]>
Date: Thu, 30 Jul 2009 11:11:24 +0200

+1.

I likewise will be unable to attend. But I think it is valuable and  
important. I do question whether perhaps it should be an IRTF effort  
rather than an IETF effort, but I think there is value in it and would  
support it being looked into.

It seems to me that there are several aspects that need consideration.  
One is the concept of multiple disparate routes being selected by the  
end station; in the Internet, the end station doesn't know anything  
about routing. In this respect, I think there are three important  
observations that could be made.

a) if there were some way to cleanly do so, such as a use of the flow  
label in some appropriate way TBD as a "route me different" flag, it  
would be nice to have the end station be able to request that the  
network deliberately spread the traffic in a stream across multiple  
routes. In the end system, if it has several appropriate addresses and/ 
or its peer does, that would include the end station sending data from/ 
to the cross product of those addresses. In the network proper,  
routers could randomly distribute traffic across equal-cost-load- 
shared paths fairly easily, and could look into less salubrious paths  
in at least some cases. In that last there be dragons, but it deserves  
looking into.

b) The set of paths so chosen will have different RTT and potentially  
other parameters. The end station will want to be aware of the impacts  
of these, and somehow prune routes (cross-products, uses of the "route  
me different" flag, etc) that aren't being helpful.

c) rather than even thinking about variations on the fast retransmit  
heuristic or SACK as currently defined, I think we need some form of  
explicit request for retransmission. One example of such an algorithm  
would be for the sender to include not only the send sequence number  
but cwnd (sender's window estimate, not receiver's buffer size) or SSN- 
cwnd in its transport header. The implication for the receiver is that  
if it receives segment SSN and is still waiting for a segment earlier  
than SSN-cwnd, it should NACK the older segment to trigger its  
retransmission. Clearly, the sender can probe for such by sending an  
empty segment that specifies cwnd=0, such as when it is terminating a  
transmission burst or has been waiting more than an RTT for an ACK and  
hasn't received it. I'm thinking along DCCP lines, therefore, in the  
use of the ACK.

On Jul 29, 2009, at 10:58 PM, Christian Vogt wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 31 Jul 2009 09:45:15 +0200

I see value in working on a "linked" congestion control scheme (work
consisting in architecting and determining how efficient such scheme
would be compared to current practice/congestion control schemes). 

I have a couple of comments/concerns though:

- The BoF presentation considers that the TCP end-points controls
routing of the traffic along a certain path in the network but routing
information does not reach the end-points. So for what it concerns
routing of the traffic, per TCP connection, there is no difference
compared to the current situation (the network is not aware that two
connections entering the network belong to the same "set"). This
assumption is to be revisited because the "possible" paths towards (set
of destinations) will be as provided by the routing system and means for
triggering and enforcing diversity inside network is not achievable
without additional mechanism (at the "networking layer" level).

Note: The term "path" is from this perspective a bit confusing i.e.
inverse multiplexed TCP or multi component TCP would probably better
suite.

- The BoF presentation considers that controlling onto which
(sub-)connection the source puts traffic leads to offload the network
from performing traffic engineering. Thus, I do not see how this would
lead to a situation where the network would be free from any traffic
engineering ? (I would even say the contrary, this would lead us back to
the hyper-aggregation problem).

- On the proposed scheme itself, if the end-points assumes that
sub-connections (say between IP Address 1 and 2) can not be
re-established after detecting their failures, the degraded state would
remain permanent since the connection between Address 1 and 2 would not
be re-established. So, it may be that some of the decisions taken by the
end-points become detrimental. At this stage, it is not clear how to
prevent such situation would happen.

Note: also that some of the RTT numbers provided in the presentations
are within recovery times achievable using fast re-routing schemes. 

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Vogt
> Sent: Wednesday, July 29, 2009 10:59 PM
> To: IETF Discussion Mailing List
> Cc: Multipath TCP Mailing List
> Subject: On Thursday's Multipath TCP BOF
> 
> Dear all -
>