Re: On Thursday's Multipath TCP BOF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+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:

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


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]