I've not bothered to track down who really said: > In most modern networks, it is important to have microflow > diversity. When IPv6 and flow-labels aren't an option, this frequently > defaults to UDP or TCP 5-tuples (src/dest IP, protocol, src/dest port) > Agreed. I would be very happy if we could even get as far as reliably > being able to use the Ipv6 flow label for this. It would allow us to > finesse a lot of the current disagreement between routing and transport. > For instance, how many issues would be solved if there were a well-known > meta-data header that an application could use to describe itself to the > network and middle boxes? Let me argue that this would be a *bad idea*. One of the characteristics of CCITT networking was that the endpoint had to declare the nature of each data stream to the network, which then allowed the network to charge "what it is worth to you" for every data stream. One of the characteristics of IETF networking is that it takes a great deal of work for the network to discern the nature (or even the identity) of each data stream, resulting in rather spastic network performance, and network capacity being purchased inexpensively, in bulk. In response, network applications have had to go through a great deal of development to allow them to work despite spastic network service. (I work in VoIP, where this is a practical problem.) Because the endpoints get to choose which sort of networking to purchase, the economic driver of Internet adoption was the absence of clear flow labeling... Dale