+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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf