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 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0