This doesn't scale well, but now I'm not sure how important that is. As long as a "good" path can be determined with no manual host configuration, then we're probably okay requiring more work for an optimal path.I agree that a few packets isn't enough to determine the bandwidth of a path but with a higher number of packets this shouldn't be much of a problem. But in these cases a partial routing table in the host would be ok, I guess. Another approach is to use diffserv to signal packets should take the high-bandwidth path.
All I mean is that if we have an architecture which allows the use of middle boxes, then a site (perhaps defined broadly enough to include a local/metropolitan/regional aggregation point) could have a set of such middle boxes. Those closer to the end host could ask those closer to the CE for path selection help.I think the right approach is to allow the functionality to be implemented hierarchically.What does that mean?
I agree, but it's equally unacceptable to prohibit it. The cases where it matters are few, but generally important to funding agencies.I'm not saying there are no benefits, just that the downsides are much bigger and that it would be unacceptable to mandate having a routing table in each host.
The upshot is that discussion of MTU is off-topic for this WG, except as a metric for path selection.I don't think setting the MTU based on the flow speed is useful: either you can do it so you do it or you can't so you don't. But I agree there isn't much point in having jumboframes in 10 or 100 Mbps equipment and it seems vendors feel the same way because I have yet to encounter a < 1000 Mbps ethernet NIC that supports them.