Real-time internet traffic is defined as datagrams that are delay sensitive. ``Real-time'' is an oft-misused term, and we are guilty here too. In process control systems, telemetry monitoring and so on, real-time really refers to systems with drop dead deadlines, after which information is irretrievably lost, or catastrophic consequences ensue if deadlines are missed. In multimedia systems, while we might have data with real time delivery requirements, we are at liberty to lose it without necessarily losing much information. We are also at liberty to relax schedules for delivery, since humans are tolerant creatures compared with machines. It could be argued that all datagrams are delay sensitive to some extent, but for these purposes we refer only to datagrams where exceeding an end-to-end delay bound of a few hundred milliseconds renders the datagrams useless for the purpose they were intended. For the purposes of this definition, TCP traffic is normally not considered to be real-time traffic, although there may be exceptions to this rule.
On congested links, best-effort service queueing delays will adversely affect real-time traffic. This does not mean that best-effort service cannot support real-time traffic - merely that congested best-effort links seriously degrade the service provided. For such congested links, a better-that-best-effort service is desirable.
To achieve this, the service model of the routers can be modified. At a minimum, FIFO queueing can be replaced by packet forwarding strategies that discriminate different ``flows'' of traffic. The idea of a flow is very general. A flow might consist of ``all marketing site web traffic'', or ``all file server traffic to and from teller machines'' or ``all traffic from the CEO's laptop wherever it is''. On the other hand, a flow might consist of a particular sequence of packets from an application in a particular machine to a peer application in another particular machine between specific times of a specific day.
Flows are typically identifiable in the Internet by the tuple: source machine, destination machine, source port, destination port, protocol any of which could be ``ANY'' (wild-carded).
In the multicast case, the destination is the group, and can be used to provide efficient aggregation.
Flow identification is called classification and a class (which can contain one or more flows) has an associated service model applied. This can default to best effort.
Through network management, we can imagine establishing classes of long lived flows - enterprise networks (``Intranets'') often enforce traffic policies that distinguish priorities which can be used to discriminate in favour of more important traffic in the event of overload (though in an under-loaded network, the effect of such policies will be invisible, and may incur no load/work in routers).
The router service model to provide such classes with different treatment can be as simple as a priority queueing system, or it can be more elaborate.
Although best-effort services can support real-time traffic, classifying real-time traffic separately from non-real-time traffic and giving real-time traffic priority treatment ensures that real-time traffic sees minimum delays. Non-real-time TCP traffic tends to be elastic in its bandwidth requirements, and will then tend to fill any remaining bandwidth.
We could imagine a future Internet with sufficient capacity to carry all of the world's telephony traffic. Since this is a relatively modest capacity requirement, it might be simpler to establish ``POTS'' (Plain Old Telephone System) as a static class which is given some fraction of the capacity overall, and then no individual call need be given an allocation (i.e. we would no longer need the call setup/tear down that was needed in the legacy POTS which was only present due to under-provisioning of trunks, and to allow the trunk exchanges the option of call blocking). The vision is of a network that is engineered with capacity for all of the average load sources to send all the time.