Dale,
I certainly wouldn't want to go to the "identify the application" stage
with the
issues that you've mentioned. I'll try to ignore the DPI and encapsulating
of
applications in UDP or HTTP to get through firewalls and so on.
What I was thinking of is more aspects like identifying a micro-flow that
shouldn't
be reordered; if an application doesn't need this treatment, that's
different.
Regards,
Alia
On Wed, Mar 19, 2014 at 7:19 PM, Dale R. Worley <worley(_at_)ariadne(_dot_)com>
wrote:
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