On Fri, 30 Jan 2004, Spencer Dawkins wrote:
Yeah, you might think that. I did, when we proposed TRIGTRAN (how
could finding out that a link failed be WRONG?).
The problem was that when we were discussing notifications like
PATH_CHANGE (or whatever we ended up calling it), the TCP has a
decision to make when it sees PATH_CHANGE - "do I
- slow start, recognizing that I now haven't got the remotest clue
what the path capacity is, or
- maintain my congestion window and try to actually LOSE something
before I decide that I need to adjust?"
TCPs have been ignoring things like ICMP Unreachable for decades, so
the second idea isn't totally bogus - they respond to actual loss, not
to the potential for loss.
Once you decide that your path change is no different than cross
traffic starting and stopping, which we adjust to after losing
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.
I understand your point, and I have heard this argument before when I
brought up the same issue in various Mobile IP meetings/talks. But I don't
agree. How is this behavior different from simply beginning a new TCP
connection with a large cwnd?
Also, if multihoming is supported at the transport so that the transport
is aware of the different paths (cwnd, ssthresh, etc), then there is a
potential of doing concurrent multipath transfer (aka load balancing, load
sharing, etc) at the transport layer. Otherwise, CMT cannot be done
well... at least not any better than an application load balancing across
multiple connections. Jana Iyengar is doing work in this area. I cc'd him
in case he wants to jump in here.
| Armando L. Caro Jr. | Protocol Engineering Lab |
| www.armandocaro.net | University of Delaware |