@Alex exactly! Someone could have designed such a protocol twenty years ago and we could all have been enjoying it. It needs to be something that can be passed on by a router and republished to hosts on the LSN too. But even with FTTP there should be a need for an information publishing protocol, like some of the functions of DHCP in certain respects. However it ought to feature not just publishing of fixed information, but also have events for notifications of state changes - such as link down/failed. Even with FTTP we want to know if the physical link fails because someone has put a digger through it or because the ONT has died / lost power or whatever. I would also like to know what the link speed up/down is; publishing that would be excellent.
With my four modems, I grope the ASCII full stats listing that I can obtain by polling the modem (which uses our very own Johnson’s firmware) and I get the up/down sync rates from that. Then I convert them into effective IP rates and put those into a customised XML config file which gets pushed into the router so that it can send stuff using the right balance of rates according to what each link can handle. Line 3 is 25% slower upstream than the others, for some completely unknown reason, so this rate split is important. I don’t know when the rates change though; I just have to use my psychic powers, so any rate change is always too late. I have no proper protocols and no event mechanism. Also I have to use forbidden knowledge to convert sync rates into IP rates based on my knowledge of the PPP-ATM-DSL protocol stack and its byte-bloat factors, knowledge which isn’t published automatically; I just have to know it. Yes, much of the particular detail will be forgotten in the FTTP era, but some basics such as link rates will still be there.
I have been thinking about how to tune TCP slow start to be less painful, wondering if you could somehow work out what the first-hop link rate is and what the path bottleneck rate is. For many hosts the first hop (discounting LAN hops to the WAN link) is the bottleneck. For servers the bottleneck could be at the far end of the path. A good way of handling the first case would be to be able to obtain link rate info from some info publishing protocol. Another method which I have thought of would be that of caching bottleneck rate info from previous TCP connections; however detecting when the path changes would be a nightmare, difficult anyway without such a protocol, especially if there is a path change in the middle of the path that creates a different bottleneck. In my setup, when the router goes into failover from DSL to 3G, then no notification of the new reduced speed can be given to hosts since we lack an appropriate protocol. (Luckily TCP just adapts, but you might not be using TCP.)