Internet differentiated services service for transaction...

Details Internet differentiated services service for transaction... Internet differentiated services service for transaction...

1998-12-28

2002-11-19

Vincent, David (Department: 2732)

Multiplex communications

Data flow congestion prevention or control

Flow control of data transmission through a network

C370S252000

Reexamination Certificate

active

06483805

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to a method and apparatus for measuring and controlling the load carried by a telecommunications system for transactional applications, and a system incorporating the same.
BACKGROUND TO THE INVENTION
Packet switched networks achieve very high speed by keeping the amount of interpretation of each packet at nodes in the heart of the network to a minimum. In general, two decisions need to be made about the packet at each node it encounters: which output link it is to be directed to; and what treatment (e.g. prioritisation) it should be given within the node, both absolutely and relative to other packets.
In production networks using the Internet Protocol version
4
(IPv
4
) the decisions have until very recently been based on a very limited subset of the fields in the IP header. Typically the output decision is made solely on the basis of the destination address. Treatments within a node are restricted to two classes of prioritisation for normal data traffic and network control traffic, based on two distinct values of the Precedence field (part of the Type of Service (ToS) octet). Network control traffic, which is generated entirely by the administrative and operational mechanisms of the network rather than by users, is typically given absolute priority over all other traffic. All user traffic (the remainder) is treated identically. Normally no guarantees are offered as to the delivery of the traffic, and the service offered to users of these networks are described as ‘best efforts’ services.
Thus in each node (router, host workstation) which routes or forwards packets in an IPv
4
, each packet which arrives on an incoming or ingress interface is treated as follows:
The packet is read from the incoming interface
The destination Address field and, optionally, the Type of Service (ToS) field are extracted from the packet
The Destination Address field and, optionally, the ToS field are used as indices into a forwarding table constructed by means of the dynamic routing protocols to find the correct output link for the packet. Routing responsive to the contents of the ToS field is currently extremely uncommon although it has in principal been available since the early definition of IP.
If the node is able to provide differential treatment of packets directed to a given output, the ToS field is inspected to determine the treatment to be given. Typically differential treatment is based on the Precedence value in the ToS field, and may be limited to two distinct classes of treatment, one for network control traffic (a small but vital component) and a second for normal data traffic (the rest); the classes of traffic are directed into a set of distinct first-in, first-out (FIFO) queues associated with each output.
The packets are scheduled into the available output bandwidth from the queues according to a scheduling algorithm. Typically this is an absolute priority mechanism in which any network control packet is given absolute priority over any normal data packet: if there are any network control packets waiting when a slot is available on the output link, the packet at the head of the network control traffic queue will be output onto the link and the packet removed from the queue in preference to any waiting normal packets. Otherwise, if there is a packet waiting on the normal data traffic queue, it will be output and removed from the queue.
Some current routers include more complex mechanisms, such as additional classification, filtering, queuing, and scheduling mechanisms but there is no uniformity as to how these facilities are invoked, and they are not widely deployed in production networks.
The limited capabilities of the existing IP networks to be able to differentiate classes of traffic restrict the ability of network operators to offer services with enhanced quality of service (QoS) to their customers. By QoS we mean such things as constraints on the delay experienced by a packet, the variation in delays experienced by a packet, the relative priority for packets of a particular class, and the amount of bandwidth available to a class of packets passing through a network.
It is becoming clear that certain customers and types or application need (and customers would be prepared to pay for) a service that is an improvement over the existing best efforts service.
One of groups of the services that is likely to be most used to users of an IP data network is transactional services. Transactional services include, but are not limited to World-Wide Web accesses and Remote Procedure Call invocations including, for example, interactive database accesses. Transactional services are a major component—perhaps as much as 70%—of today's data traffic.
Within an IP packet switched data network all data is carried in the form of IP ‘datagrams’. An IP datagram is a packet consisting of an IP header and an IP payload as shown in FIG.
2
.
The IP Header provides all the information needed to route the packet through the network.
IP datagrams are used to carry the information of numerous different protocols across the network (the protocol in use is indicated by a specific bit pattern in the Protocol field of the IP header). One of these protocols is the Transport Control Protocol (TCP) reliable byte stream transport protocol. In this case the IP payload is made up of a TCP header and the TCP user payload data. TCP is used as the transporting protocol for a large fraction of all user traffic carried across IP networks.
The TCP header is used to carry information which allows the receiving station to reconstruct the transmitted byte stream thereby achieving the desired reliability of delivery. Packets successfully received at the receiving end of a connection are positively acknowledged by the sending of a specific acknowledgement back to the origin of the packet.
A fundamental characteristic of TCP is its ability to adapt the rate of flow of data across a network to provide near optimal use of the available network bandwidth. TCP conforms its transmission rate to the available bandwidth by:
Increasing its transmission rate in response to successful receipt and acknowledgement of packets
Reducing its transmission rate in response to missing acknowledgements, indicating packet loss (typically due to network congestion).
In normal operation, the flow rate of a TCP flow starts at a low value and ramps up through a ‘slow start phase’ and a ‘congestion avoidance phase’ to a maximum value as the first few packets are acknowledged. At some point in this initial ramp up either all data will have been sent or a packet will be lost. If a packet is lost (indicated by missing acknowledgements) the flow rate is reduced by 50% and ramp up restarts from the reduced value.
If multiple packets are lost, the flow is reduced to a minimum and the whole process repeats after a delay designed to allow the network to recover from the congestion that caused the dropped packets. Typically transactional services open a TCP reliable byte stream connection from a client to a server and issue a ‘request’ which is in the order of a few tens to a few hundreds of bytes long (i.e. one or two packets). The request is sent from the client to a server which processes it, performing some local operation and then returns some ‘response’ data which may vary from a few bytes (such as a success code) to a few tens of kilobytes (such as an image for a web page) over a period of between, say, a few hundred milliseconds to 20 seconds.
One problem in integrating such transactional services into most standard QoS schemes is that the overhead of reserving resources to guarantee the delivery of the data is out of proportion to the size of the data delivered and the limited persistence of the connection. Each transaction or small set of transactions is likely to need a separate reservation especially in the web access service case.
A further problem lies in that the short duration of the flow associated with a request or response does not allow the conventional flow control algorithms of TCP

Affiliated with

Also associated with

Rating

Internet differentiated services service for transaction... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Internet differentiated services service for transaction..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Internet differentiated services service for transaction... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2916037