>>> 6to4 is a crapshoot, it can be reasonable or it can completely fail, >>> with everything in between. But it's never going to be better than >>> native IPv4, obviously. >> No, not obviously - because if the application has a need to do >> address referral then there are conditions in which the 6to4 address >> will work better. > > I was talking about performance. I guess even there there are a few > cases where 6to4 can do better than the IPv4 it's carried over, but > that should be rare. More common than you might think, especially given that native IPv4 is often subject to traffic filters that might not apply to 6to4. >>> I agree that this is an important issue, but I fail to see how this >>> relates to applications knowing about addresses, unless applications >>> are going to do their own performance testing, which I don't recommend. >> p2p applications are doing this already. > > Do you mean BitTorrent? Those applications don't really test > performance, but simply use different addresses concurrently. Which is > an excellent way to make the question of which address performs better > moot, by the way. The applications that do that still have to deal with addresses explicitly. p2p transfer of large file is sort of a special case since you can generally afford to spend some time learning which paths are more efficient. >>> As I said, a good start would be that API because once applications >>> use it, people working on better address selection etc have a place >>> to insert their stuff and improve performance of real applications >>> without having to rewrite the application. >> I spent a fair amount of time trying to come up with an API that >> would let applications push this decision-making to a lower layer >> while allowing that lower layer to make those decisions effectively >> based on the needs of that particular application. That API ended up >> looking fairly complex. There are lots of factors that influence >> address selection. > > Yes, communicating application needs back and forth would be tricky. > For instance, suppose I have two links: one is 2 Mbps ADSL. This is > not so bad that an application can't run, but if my other link is 1000 > Mbps, then the application would probably want to use that link. But > the application doesn't know if that's the case, it could also be a > GPRS link with enormous latency and virtually no bandwidth. So what > does the application say? The application says something like "I need a minimum of X Mb/s bandwidth" (which implies, e.g. don't use any interface that can't provide that) or "I don't need much bandwidth but I do need a connection that's going to stay up for awhile" (e.g. use the GPRS interface or maybe the mobile IP in-care-of address) or "I need as much bandwidth as possible but I don't expect the connection to need to stay up very long". (use the fastest path available or maybe even more than one path concurrently) or "I need the best latency I can get but the amount of data transferred will be small and the duration will be short". Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf