Internet DRAFT - draft-shyam-rt-pkt-transport
draft-shyam-rt-pkt-transport
INTERNET DRAFT S. Bandyopadhyay
draft-shyam-rt-pkt-transport-00.txt March 18, 2014
Intended status: Informational
Expires: September 18, 2014
An approach of transportation of RT packets through IP
switch based networks to achieve the best performance.
draft-shyam-rt-pkt-transport-00.txt
Abstract
This document intends to find out the size of an IP packet at which
VoIP applications will produce the best result. It emphasizes the
physical phenomenon because of which ATM networks perform better than
the IP switch based networks and tries to come out with an approach
by which IP switch based network can perform as good as ATM network
for the processing of real time traffic.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Bandyopadhyay Expires September 18, 2014 [Page 1]
Internet Draft RT packet transport through IP switches March 18, 2014
1. Introduction
Traditionally ATM network performs faster than the IP switch based
network. The difference becomes more prominent for real time
applications. Whereas they have disadvantages as far as bandwidth
usages is concerned compared to the IP-switch based network. This
document tries to address approaches for IP-switch based network to
process real-time applications as fast as ATM network.
2. Processing of real time packets
Here is an attempt to come out with a solution for IP switch based
network to operate in the most user-friendly manner to transport data
traffic (IP) as well as real time (RT) traffic (as RTP[1] packet) in
the existing 32-bit system.
In case of IP routing/switching entire packet gets collected at the
intermediate router/switch and forwarded based on the forwarding
table. Inside the switch/router the variable length IP packet gets
fragmented into smaller size frames at the ingress side. The frames
gets transported through the switching fabric with proper priority
mechanism (to support QoS) and then reassembled at the egress side
and passed through the media for the next hop.
In case of ATM, packets get fragmented at the ingress edge devices
into small size cells. Entire packet gets transported as a stream of
cells and gets collected at the egress edge device. The success of
ATM over IP routing as far as speed is concerned is due to the fact
that the latency gets reduced as the entire packet does not get
collected, fragmented and reassembled at the intermediate nodes. So,
in case of IP switch based network, if RT packets can be passed
without getting fragmented inside the switch, better performance can
be expected. i.e. one RT packet needs to get to fit inside one
internal frame of the switch fabric. Additionally, to make this
approach successful, maximum size of MPLS[2] label stack has to be
defined. Inside the switch all the IP packets will be assumed to
carry same number of MPLS labels whether they are having one or the
maximum in real sense. In fact, to reduce overhead, this limit should
be the minimum number of labels needed to satisfy all sorts of
features supported by MPLS. i.e. label stacking of depth n (without
limit) needs modification.
If minimum frame size is selected to fit one RTP packet, overhead
becomes too high due to very large (40 bytes: 20 bytes IP + 8bytes
UDP + 12 bytes RTP) packet header. Again, if large frame size is
used, fragmentation loss becomes too high for the small size packets
(say, 40 bytes IP packets). So, a compromise is needed that will give
a better result based on the IP packet size distribution. Frame size
Bandyopadhyay Expires September 18, 2014 [Page 2]
Internet Draft RT packet transport through IP switches March 18, 2014
is selected based on the minimum value of the overhead due to the
fragmentation loss of data packet as well as the overhead as header
of the RT packets.
Studies show that primarily IP data packets of three different sizes
are found common in nature. Almost
~50% packets of size 40 bytes (TCP ACK),
~20% packets of size 576 bytes (path MTU set by X.25) and
~30% packets of size 1500 bytes (path MTU set by ethernet)
Other packets are less compared to the above three categories and
almost evenly distributed. For the sake of simplicity of calculation,
traffic of the first three categories are only considered. Payload of
the data traffic is the actual IP packet size where as the payload of
RT traffic is the payload inside RTP packet.
If totBytes are to be transported across the internet and dataPcnt be
the %of data traffic,
totBytes*dataPcnt/100 = data traffic and
(100-dataPcnt)*totBytes/100 = RT traffic;
Out of data traffic 50% of 40 bytes length; 20% of 576 bytes length;&
30% of 1500 bytes length.
If totDataPkts be the total data packets,
totDataPkts*(50*40/100 + 20*576/100 + 30*1500/100) =
totBytes*dataPcnt/100;
or, totDataPkts*58520 = totBytes*dataPcnt;
Let totBytes = 58520*100, for the ease of calculation;
i.e. totDataPkt = dataPcnt*100;
40 bytes packets = 50*totDataPkt/100 i.e. 50*dataPcnt
576 bytes packets = 20*totDataPkt/100 i.e. 20*dataPcnt
1500 bytes packets = 30*totDataPkt/100 i.e. 30*dataPcnt
RT packets = totBytes * (100 - dataPcnt)/100
= 58520 * (100-dataPcnt);
If n is considered to be the depth of MPLS label stack,
inside the switch, actual size of
40 bytes packet = 40+4*n bytes,
576 bytes packet = 576+4*n bytes &
1500 bytes packet = 1500+4*n bytes
Let frameSize be the payload of a frame (excluding the frame header)
inside the switch. If a RT packet fits exactly inside frameSize,
RT packet payload = (frameSize-40-4*n) bytes;
Bandyopadhyay Expires September 18, 2014 [Page 3]
Internet Draft RT packet transport through IP switches March 18, 2014
Total overhead = packet header overhead (of RT packets) +
fragmentation overhead (of data packets);
If a plot is drawn for frameSize = 40+4*n+1 to 1500+4*n for different
dataPcnt (with dataPcnt=80 to 100) minimum of overhead are found at
frameSize = (84, 101, 118, 126 and 152) for n==3; frameSize = (119,
127 and 152) for n==4 and at frameSize = (118, 127 and 152) for n==5.
Actual data of the IP traffic has to be collected to get the best
result. As dataPcnt increases minimum values are found at a lower
frameSize and it gives better result with the higher range for lower
dataPcnt. With average IP packet size 585 bytes, switches will
encounter a loss of 4*(n-1) bytes for packets that will need only one
label.
In order to make this scheme work, a standard for maximum label stack
size has to be defined. RTP packet size also has to be standardized.
The same scheme is applicable to all the switching systems where IP
packets get transported in hop by hop basis unlike the way it works
in ATM networks.
2.1. Dual mode operation
Inside ingress as well as in the egress card, packets need to follow
certain functional steps. In order to maximize the output, a series
of processing units work in pipeline mode for these operations.
Ingress service cards need to act in dual mode to process RT packets
and non-RT packets. i.e. the RT packets should follow a direct path
that won't need fragmentation and related complexities before they
are sent to the VOQs (virtual output queues, where from packets gets
picked up to be sent to the switching fabric). Whereas other packets
need to follow a different path for fragmentation operations. This
will prevent a RT packet to be blocked by the fragmentation procedure
of not-RT packets that arrive in the service card prior to the
arrival of RT packet. So, mere mapping of RT packet size with the
frameSize of switch fabric will not achieve the speed of ATM
switches.
Simulation studies show that significant improvement is achieved once
RT packets are directly sent to VOQs after the operation of label
processing. It will be worth to study by the hardware people to
figure out whether entire set of data can be placed into queues based
on their priorities and segmentation operation is done in each queue
in parallel mode before putting the frames into their respective
VOQs. Entire operation will be lot costlier, but simulation result
shows that in such case, RT packets need not be restricted to fixed
size cells. Standardization of label stack depth need not be imposed
as well.
Bandyopadhyay Expires September 18, 2014 [Page 4]
Internet Draft RT packet transport through IP switches March 18, 2014
2.2. Expected changes at the application layer
IP packets with size 576 in most of the cases come out of those TCP
layers that do not process maximum path-MTU and takes the default one
that was set during X.25. The 576 factor can be corrected very easily
with path-MTU set to 1500. Also, in case of next generation IP,
header of IP packets will be different. Switch fabric frame size
needs to be determined keeping these two factors in mind. With the
existing 32-bit system, frame size (excluding the frame header) of
152 and 127 are most viable solution in general for label stack
depth=3,4 &5.
3. Security Consideration
This document does not include any security related issues.
4. Acknowledgments
The author would like to thank to Professor Amitava Datta of
University of Western Australia for his review and constructive
comments.
5. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson.
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
6. Author's Address
Shyamaprasad Bandyopadhyay
HL No 205/157/7, Inda
Kharagpur 721305, India
Phone: +91 3222 225137
e-mail: shyamb66@gmail.com
Bandyopadhyay Expires September 18, 2014 [Page 5]
