Hi Spencer/Armando,
I haven't been following this discussion through.. so let me know if I'm
going off track.
> On Fri, 30 Jan 2004, Spencer Dawkins wrote:
>
> > something, transports ignoring path changes makes a lot of sense. If
> > you are changing paths frequently (and round-robin would be the
> > limiting case), slow-starting every time you change paths is
> > excessive - and, if you're going to respond to PATH_CHANGE, what else
> > would you do? You could do congestion avoidance during the first round
> > trip, or actually lose something and do congestion avoidance on the
> > second round trip - not a big difference, conceptually.
Lets assume that the sending transport is allowed to maintain separate
congestion control parameters per path to the destination. I think this
debate about what the sender should do on each PATH_CHANGE would be easier
to resolve with per-path congestion control. The sender may not have to
slow-start on each PATH_CHANGE *if* the sender has "recently" used that
path to send data. Thus, if the sender is changing paths frequently enough
to be sending data on multiple paths concurrently, the sender can evolve
multiple independent cwnds concurrently. If not, a slow-start should not
hurt much. Of course, this is possible only if multihoming is supported at
the transport.
Further, having a multipath aware transport allows us to encode "correct"
Concurrent Multipath Transfer (CMT, or end-to-end load balancing) into the
transport, as against possibly aggressive CMT by an application. A feature
such as PATH_CHANGE is very enticing for app developers to use for CMT.
regards,
jana
---------------------------------------------------------------
Visit www.narmada.org, www.indiatogether.org
---------------------------------------------------------------