EP1323268A2 - Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence - Google Patents

Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence

Info

Publication number
EP1323268A2
EP1323268A2 EP01975896A EP01975896A EP1323268A2 EP 1323268 A2 EP1323268 A2 EP 1323268A2 EP 01975896 A EP01975896 A EP 01975896A EP 01975896 A EP01975896 A EP 01975896A EP 1323268 A2 EP1323268 A2 EP 1323268A2
Authority
EP
European Patent Office
Prior art keywords
delay
traffic
access
request
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01975896A
Other languages
German (de)
English (en)
Inventor
François F. BLOUIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nortel Networks Ltd
Original Assignee
Nortel Networks Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nortel Networks Ltd filed Critical Nortel Networks Ltd
Publication of EP1323268A2 publication Critical patent/EP1323268A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/821—Prioritising resource allocation or reservation requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6445—Admission control
    • H04L2012/6456—Channel and bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6464—Priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6472—Internet

Definitions

  • the invention generally resides in the field of handling multimedia traffic in a communications network domain, hi particular, the invention is concerned with voice and data traffic in TCP/IP sharing an access to a network.
  • a communications network handles data traffic among many computers, printers, servers, and other end devices (data terminals).
  • the network can be in the form of an Ethernet, token ring, switching network or other.
  • each of these end devices has a dedicated access (sometimes called a network drop or simply a drop) connecting to the network, h a typical office environment, telephone sets are also essential equipment and generally form a separate telephone network among them.
  • Two separate networks require additional cost for installation, maintenance, etc and also lead to an inefficient use of network resources such as bandwidth.
  • Telephone sets can connect to and share the communications network with data terminals. This will do away with the telephone network, resulting an economical benefit.
  • Each telephone set can connect to the communications network by a dedicated drop like other end devices but as an office generally requires a data terminal and a voice terminal (e.g., telephone set) at close proximity to one another, it would be beneficial if both terminals can share one drop.
  • a switch on a shared drop can control the traffic to/from a data terminal or voice terminal, giving the voice traffic a priority over the data traffic. Switches, however, are an expensive hardware and providing a switch on each shared drop increases the cost even more and is not very practical. Hubs also allow different traffic to share an access but they have a problem of collision that must be addressed.
  • TCP/TP and UDP/TP are widely popular protocols for transferring data in packets through networks.
  • TCP Transmission Control Protocol
  • Delay insensitive traffic such as file transfer, transactions on the web etc. use mainly TCP/IP.
  • UDP User Datagram Protocol
  • Each UDP header carries both a source port identifier and destination port identifier, allowing high-level protocols to target specific applications and services among host.
  • UDP packets are suitable for sending delay sensitive traffic such as voice etc.
  • the invention addresses problems associated with provisioning a data terminal and a voice terminal on a shared drop, h one aspect, the invention resides in TCP/IP and UDP/IP environment and it configures dynamically TCP settings to provide low latency voice delay by prioritizing voice over delay insensitive data packet, hi a further aspect, the invention contemplates the use of a
  • the present invention relates to a method of sharing an access to a communications network by a delay sensitive traffic in UDP/TP and a delay insensitive traffic in TCP/IP.
  • the method includes steps of adjusting an ACK delay parameter for the delay insensitive traffic by a desired amount in response to a request for a delay sensitive traffic and sending the delay sensitive traffic in a series of UDP packets through the access.
  • the method further includes a step of sending an acknowledgment of a reception of delay insensitive traffic through the access at the adjusted ACK delay parameter.
  • the invention is directed to a communications module for permitting delay sensitive UDP/IP traffic and delay insensitive TCP/IP traffic to share an access to a communications network.
  • the communication module comprises a detection unit for detecting a request for a delay sensitive UDP traffic. It also includes a request generating unit for generating a request signal in response to the request and sending the request signal to a TCP/IP unit of the delay insensitive TCP/TP traffic. ' The request signal contains an instruction for the TCP/IP unit to adjust the ACK delay parameter.
  • the invention is directed to a hub in an access to a communications network for allowing a delay sensitive UDP/IP traffic and a delay insensitive TCP/IP traffic to share the access.
  • the hub comprises a first port for exchanging the delay sensitive UDP/IP traffic, a second port for exchanging the delay insensitive TCP/IP traffic and a third port for exchanging both delay sensitive UDP/IP traffic and delay insensitive TCP/IP traffic with the communications network.
  • the hub further includes a detection unit for detecting a request for a delay sensitive UDP traffic, and a request generating unit for generating a request signal in response to the request and for sending the request signal to a TCP/IP unit for the delay insensitive TCP/ff traffic.
  • the request signal contains an instruction for the TCP/IP unit to adjust the ACK delay parameter.
  • the invention is directed to a telephone set for sharing an access to a communications network with an end device which generates a delay insensitive TCP/IP traffic.
  • the telephone set includes a request detection unit for detecting a request for delay sensitive UDP traffic and in response to the request.
  • the set further includes a request generating unit for generating a request signal and sending the request signal to a TCP/IP unit for the delay insensitive TCP/IP traffic, the request containing an instruction for the TCP/IP unit to adjust the ACK delay parameter, and a DSP module for generating a series of UDP packets in response to an audio input of the telephone set and sending the series of UDP packets through the access.
  • the invention is directed to a computer terminal operating in TCP/IP for sharing an access to a communications network with a telephone set which generates a delay sensitive UDP/IP traffic.
  • the computer terminal includes a request detector for detecting a request for delay sensitive UDP/IP traffic and a request generating unit for generating a request signal, the request signal containing an instruction for the computer terminal to adjust the ACK delay parameter.
  • the terminal further includes a TCP/IP unit for adjusting the ACK delay parameter in response to the request signal.
  • the invention is directed to a first computer terminal operating in TCP/IP for sharing an access to a communications network with a second computer terminal which generates a delay sensitive voice traffic in the form of UDP/IP packets.
  • the first computer terminal includes a request detector for detecting a request for delay sensitive UDP/TP traffic from the second computer and a request generating unit for generating a request signal, the request signal containing an instruction for the first computer terminal to adjust the ACK delay parameter.
  • the first terminal further includes a TCP/IP unit for adjusting the ACK delay parameter in response to the request signal.
  • FIG 1 shows a communications environment in which the present invention finds its applications.
  • Figure 2 shows the operation of a switch.
  • Figure 3 shows the operation of a hub.
  • Figure 4 depicts an Ethernet communications network connecting variety of end terminals with shared drops.
  • Figure 5 illustrates voice traffic in UDP packets on an access to an
  • Figure 6 illustrates data traffic in TCP packets on an access to an Ethernet network.
  • Figure 7 shows data traffic in TCP packets on an access to an Ethernet network when the piggyback feature is used.
  • Figure 8 is a timing diagram and call process chart showing functional phases of one embodiment of the invention.
  • Figure 9 is a flow chart of processing a voice call request and adjusting the ACK delay parameter.
  • Figure 10 illustrates voice in UDP packets and data traffic in TCP packets sharing an access to an Ethernet network in accordance with one embodiment of the invention.
  • Figure 11 is a block diagram of a hardware configuration of a processing module according to an embodiment of the present invention.
  • Figure 12 is a block diagram of a few embodiments of the present invention, showing possible locations of the processing module.
  • Figure 13 is a block diagram of a further embodiments of the present invention, showing a pair of computers having voice capabilities.
  • Figures 14, 15, 16, 17, 18 and 19 show simulation results at either the standard (default) setting of 10 ms or the increased delay setting of 200 ms.
  • a communications network 10 includes a plurality of drops connecting telephone sets 12, computers 14, servers 16, printers 18 and other end devices. It also has a connection to other networks 20 by way of a gateway 22.
  • a telephone set and a computer share a single drop 24 connecting to the network by way of a module 26.
  • the module can take a form of a switch. Switches are a layer-2 device (e.g., IP layer).
  • a switch 30 includes a scheduler 32 and buffers 34. Traffic from a plurality of input ports 36 is stored in the buffer and the scheduler controls a proper order of traffic when outputting from an output port 38. h the present circumstance, a switch requires only three ports, one to a telephone set, another to a data terminal and the third being an uplink to the network. As mentioned above, switches are a costly hardware, even when it only deals with three ports.
  • Hubs are a layer- 1 device. They are also known as a repeater and operate in half duplex, that is to say, traffic only travels in both directions but in one direction at a time.
  • Figure 3 shows an n-port hub 40. When a hub receives traffic at one port 42, it copies to all the remaining ports 44. A device of layer-2 or higher connected to each remaining port decides whether to accept or ignore the copied traffic. Hubs are simpler and less costly than switches but hubs encounter collisions which need to be addressed. When a hub receives incoming traffic at two or more ports at a same time, a collision occurs, resulting in corrupted or dropped data from the traffic.
  • a transmitting end device when a transmitting end device senses a collision, it backs off from transmitting and waits for a certain period of time before it attempts a retransmit. All the transmitting end devices wait for different periods to avoid repeated collisions. Different types of network use different mechanisms for avoiding or eliminating collisions.
  • the present invention proposes mechanisms which lessen the problem of collisions when delay sensitive and delay insensitive traffic share an access to a network.
  • the invention uses a 3-port hub as a module shown in Figure 1.
  • a computer 50 is exchanging data with a FTP server, web server or the like 52 through a network 54, using TCP packets.
  • a telephone set 56 includes a feature which permits to transmit and receive voice traffic in UDP packets. Such telephone sets are available now on the market as IP phones.
  • a hub 58 in cooperation with a call server 60 permits the sharing of a drop 62 by the computer and the telephone set.
  • the network in this embodiment is an Ethernet network but other types of network e.g., PSTN, ATM, Token Ring, FDDI, PPP etc. are also possible.
  • Voice on a telephone set is generally sampled for 10-30 ms (milliseconds) and another 10-15 ms is required to processing, packetization etc of sampled data. This would produce over 20 samples/second (sampling rate). With some overhead etc., a sampling duration of 30 ms produces a UDP packet of 280 bytes long at each sampling.
  • the voice packets or voice UDP packets can be processed and compressed to suite for transport over a specific network. Each UDP packet therefore carries each sampled voice datum.
  • each voice UDP packet (280 bytes in size) would have a duration of about 224 ⁇ s (microseconds).
  • voice UDP packets are uniformly transmitted through the network or uniformly received by the destination telephone set at the same sampling rate (e.g., 45 ms apart at 22 samples /second) and without a large end-to-end delay.
  • Figure 5 shows voice traffic of the example described above on a lOBaseT
  • Ethernet the horizontal axis showing the time t (or translated into number of bytes).
  • Mb/s 10 million bits per second
  • the Figure shows a plurality of voice UDP packets 72, each of which is 224 ⁇ s (280 bytes) in duration. Two adjacent UDP packets are at least 45 ms (56250 bytes) apart.
  • FIG. 6 shows data traffic on a lOBaseT Ethernet network.
  • the traffic may be of an FTP transaction between the computer and a server, printing a file off a printer, or an HTTP transaction on the web etc.
  • the transaction is in a plurality of TCP packets, each of which can be theoretically up to 65,000 bytes long.
  • An Ethernet limits the maximum size of packets to 1,500 bytes (equivalent of 1.2 ms on lObaseT).
  • TCP protocol features an ACK mechanism for TCP packets to ensure proper delivery of packets.
  • the end devices use sequence numbers indicating sent or received data for the ACK mechanism and the sliding window mechanism for flow control.
  • an end device When an end device receives TCP packets, it sends an ACK signal to the transmitting end device, informing the reception of packets by using the sequence numbers. The transmitting end device waits for the ACK signal before it transmits the next TCP packet.
  • a transmission may contain more than one packet and a group of packets in one transmission is called a segment. Both end devices use the sliding window mechanism to inform each other how large the next segment can be.
  • TCP also provides a time-out period of e.g., 1-2 seconds. If an end device does not receive an expected ACK signal and the time-out period elapses, the end device assumes that the transmitted packets lost and retransmits the lost TCP packet or packets.
  • each end device is designed to send an ACK signal to the transmitting end device within an ACK delay parameter of the reception of packets.
  • Each end device can set its own ACK delay parameter.
  • the ACK delay parameter obviously must be less than the time-out period or the transmitting end device will perform a retransmit.
  • the ACK delay parameters can be set in terms of a time on a clock or by the number of segments transmitted. By clock, the delay can be set by a time period of e.g., from 1 ms to 200 ms. It can also be set by the segment so that in one example it can be set to acknowledge every other segment, taking into consideration of the time-out period.
  • a receiving end device can send an independent ACK signal according to the ACK delay parameters.
  • TCP packets are variable in size and travel in one direction, while the ACK signals in the opposite direction. Because Ethernet networks are bus network, the figures are considered to depict the periods of the bus being driven by one end device. Some example values of TCP packet's sizes are given in the figure, but generally much longer than voice UDP packets discussed above.
  • a period between an ACK signal and the next TCP packet depend on the availability of packets to be sent and processing time at the transmitting end device, hi the Figure, a data terminal for example is set to send an ACK signal 10 ms after the reception of a TCP packet. At 86, for some reason 10 ms elapsed and no ACK signal was sent. This happened, for example, when another end device attempted to drive the bus coincidentally with the ACK signal and caused a collision. A retransmit 88 of the presumed lost TCP packet followed.
  • Figure 7 shows traffic when two end devices are using the piggyback feature by which an ACK signal is concatenated to a TCP packet being transmitted. In this example, each end device alternately drives the bus to send its TCP packet.
  • One end device has the ACK delay parameter set at 10 ms and the other at 15 ms.
  • UDP packets are continuously sent and there is no ACK mechanism in transporting data.
  • Voice UDP packets should travel through the network with as little delays and as uniformly apart from one another as possible.
  • the end-to-end delay of more than 150 ms is considered unacceptable for voice data. If some voice UDP packets experience more than 150 ms of delay, voice would suffer from noise, distortion, voice clipping etc.
  • TCP packets of file transfer etc. are generally large in size but they are not sensitive to delay. Proper delivery is more important in those situations and the ACK mechanism ensures it.
  • TCP packets prompt ACK signals within an ACK delay parameter, e.g., 10 ms after reception or every other segments received for the transmitting end device to continue further transmission.
  • TCP The shared access to the network becomes available when no traffic exists on the access.
  • both packets, UDP and TCP compete equally for access.
  • TCP packets are, however, generally longer and variable in size than voice UDP packets which are also spaced further apart. In competing with TCP packets, therefore, voice UDP packets experience variable and often unacceptably large delays.
  • the voice UDP packet has very little chance to seize the shared access until the TCP finish the transaction, if the ACK delay parameter is set at e.g., 10 ms (normally a default value).
  • TCP has many parameters that can be tuned to achieve different level of transmission and bandwidth utilization.
  • the default windows setting (10 ms delay parameter setting) is for the fastest transmission and no bandwidth sharing with other devices on the same collision domain e.g., the same Ethernet.
  • TCP traffic can be slowed down in order to give up some bandwidth of the shared access to delay sensitive traffic such as voice traffic. For example as one embodiment, by modifying the TCP ACK delay parameter, priority can be given to voice UDP packets while TCP data traffic throughput is reduced.
  • the TCP ACK delay parameter can be increased from the typical 10 ms to 200 ms at an end device which shares an access with a voice terminal. This will leave a gap of e.g., 200 ms before the end device sends an ACK signal, thus making the other end device to slow down the transmission of further packets. Voice UDP packets can be inserted into this gap.
  • the new setting of ACK delay parameter can be empirically determined or adjusted for desired performance.
  • the voice traffic should not suffer an end-to- end-delay of more than 150 ms. It can intuitively be predicted that as the ACK delay parameter is increased, the end-to-end delay performance of voice traffic should improve to a certain level where the performance should level out while the throughput of TCP packets continues to decrease with the increased setting of ACK delay parameter.
  • the TCP time-out setting will determine the maximum setting of ACK delay parameter.
  • the ACK delay parameter is reset to a default value.
  • the ACK delay parameters are dynamically set, that is to say, whenever a voice call is requested, the data terminal is informed of the voice call request and instructed to set the ACK delay parameter to a new increased setting.
  • Each voice terminal on the network may have a feature that informs the sharing data terminal of a voice call request which is generally indicated by a telephone receiver going off-hook or some such signal.
  • the network has a call server to which voice terminals on the network send a voice call request prior to initiate the voice call.
  • the call server uses some criteria e.g., bandwidth, capability of voice terminal etc. and determines if a voice call can be accepted.
  • the call server informs the voice terminal which in turn informs its access sharing data terminal to set a new ACK delay parameter setting because a voice call will start soon.
  • the data terminal performs or continues to perform a TCP transaction under the new setting while the voice call is in progress.
  • the data terminal Upon termination of the voice call, the data terminal reset the ACK delay parameter.
  • FIG. 8 shows call flows at some phases of operation of one preferred embodiment of the invention.
  • An IP phone informs a call server that it desires to make a phone call to another IP phone, by sending a call request.
  • the call server accepts or denies the call request, based on criteria, e.g., the availability of bandwidth, etc.
  • the IP phone sends a message to its neighbor end device e.g., a PC (on the same shared hub) to notify the PC that a voice call will start soon and its TCP settings should be configured to allow voice packets to be sent out with minimum delay.
  • a PC on the same shared hub
  • Voice call is established between two IP phones on the network. Voice UDP packets are transmitted at an interval shown by 90
  • PC data transfer is executed while the voice call is in progress.
  • the new delay parameter setting is shown by 92.
  • the new TCP settings allow for both voice and data traffic to be transferred on the shared hub while maintaining adequate voice end-to-end delay of less than 100 or 150 ms.
  • the data traffic between the PC and a web server or file server continues with an increased delay.
  • Figure 9 shows a flow chart of the operation shown in Figure 8. If there is either a voice call request or a voice call termination request is received at 100, either request instructs a TCP unit located at a computer terminal to adjust the ACL delay parameter at 102. In parallel at 104, an IP phone starts or receives voice UDP packets. Meanwhile if TCP packets are received at 106, the TCP unit sends ACK in accordance with the adjusted ACK delay parameter at 108. When a voice termination request is received at 110, it is detected and the ACK delay parameter is adjusted again, likely back to the default setting.
  • Figure 10 shows the sharing of the access by both voice UDP packets and
  • TCP packets according to one embodiment of the invention, hi the Figure, voice UDP packets are permitted to travel at 45 ms interval, while TCP packets experience differing and generally longer delays.
  • the invention can be realized in a processing module 120.
  • the processing module could be located at an IP phone or a computer terminal which shares the access with the IP phone or a hub.
  • the call server located at another location on the network as shown in
  • the processing module contains a request detector unit 122 which detects a telephone set going off-hook or a similar signal, indicating that a delay sensitive UDP (a voice call) is requested.
  • the request detector unit in one embodiment detects also presence or termination of voice call.
  • request generator 126 Upon detection of the off-hook condition and under control of a controller 124, request generator 126 generates a request for UDP traffic and sends the request to the computer terminal, instructing to adjust the ACK delay parameter of a TCP/IP module to a new setting.
  • the controller refers to a memory 128 for stored information such as addresses of a calling and called party and other relevant data to the hub, computer terminal or call server.
  • the processing unit When the processing module is located at the computer terminal, the processing unit directly instructs the TCP/IP module of the computer terminal to adjust the ACK delay parameter.
  • the controller When the termination of voice call (UDP packets) is detected, the controller indicates such condition to the TCP/IP module which then resets the ACK delay parameter to the initial value.
  • Figure 12 shows possible locations of processing module 130.
  • an IP phone 132 contains a DSP module 134 for processing and packetizing audio input to generate series of UDP packets.
  • a computer terminal 136 requires a TCP/IP processing unit 138 in addition to other essential component such as computer processor 140.
  • a processing module can be located at a hub 142 which contains a necessary hub function units 144.
  • Figure 13 shows another embodiment in which a pair of computers shares an access. Both or one of the computers contains a voice processing software for generating voice UDP packets, thus functioning as a voice terminal.
  • Figures 14-19 show simulation results at either the standard (default) setting of 10 ms or the increased setting of 200 ms. The horizontal axes are in arbitrary time scale.
  • Figure 14 includes two graphical representations in the same time scale of an end-to-end delay (in second) and counts of collision transmission attempt under standard TCP settings.
  • Figure 15 includes two graphical representations in the same time scale of an end-to-end delay (in second) and counts of collision/transmission attempt under a new ACK delay setting of 200 ms.
  • the upper graph shows that there are many voice packets which experienced over 0.1 second (100 ms) delay and there are substantial packets with more than 150 ms delay.
  • Figure 15 there is only one instance in which a packet experienced a delay of a little over 0.08 seconds (80 ms), all the remaining voice packets being delayed less than 80 ms.
  • the lower graph shows that almost 50% success rate throughout the voice call.
  • Figures 16 and 17 each includes two graphical representations of voice delay distribution respectively under standard TCP settings and under a new ACK delay setting of 200 ms.
  • Figures 16 and 17 used same data as those used in Figures 14 and 15 but show them differently. Therefore, Figures 16 and 17 correspond to Figures 14 and 15 respectively.
  • Figures 18 and 19 show groups of graphical representations of voice sharing with a 10 M bytes FTP transaction under the TCP standard and under the new setting of 200ms ACK delay parameter respectively.

Abstract

Il existe de nombreuses circonstances dans lesquelles un trafic sensible au temps de propagation et un trafic non sensible au temps de propagation partagent un accès à un réseau de télécommunication. Le protocole TCP/IP est bien adapté pour la distribution du trafic non sensible au temps de propagation alors que le trafic sensible au temps de propagation utilise le protocole UDP/IP. Lorsqu'un trafic sensible au temps de propagation par paquets UDP/IP est en cours, le paramètre de retard ACK dans le protocole TCP/IP peut être réglé de façon que les paquets UDP puissent être insérés parmi les paquets TCP afin de réduire les collisions et le retard de bout en bout des paquets UDP.
EP01975896A 2000-09-19 2001-09-17 Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence Withdrawn EP1323268A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US664712 1996-06-17
US66471200A 2000-09-19 2000-09-19
PCT/CA2001/001313 WO2002025880A2 (fr) 2000-09-19 2001-09-17 Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence

Publications (1)

Publication Number Publication Date
EP1323268A2 true EP1323268A2 (fr) 2003-07-02

Family

ID=24667143

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01975896A Withdrawn EP1323268A2 (fr) 2000-09-19 2001-09-17 Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence

Country Status (4)

Country Link
EP (1) EP1323268A2 (fr)
AU (1) AU2001295307A1 (fr)
CA (1) CA2422919A1 (fr)
WO (1) WO2002025880A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200408242A (en) 2002-09-06 2004-05-16 Matsushita Electric Ind Co Ltd Home terminal apparatus and communication system
EP1868327A3 (fr) * 2003-10-10 2012-01-04 Thomson Licensing Contrôle de l'allocation de bande passante des données par paquets
EP1687940B1 (fr) * 2003-10-10 2013-01-09 Thomson Licensing Priorite au protocole de datagramme d'utilisateur par rapport au trafic de protocole de controle de transmission par ralentissement du debit de transmission du protocole de controle de transmission
WO2006109006A1 (fr) * 2005-04-14 2006-10-19 Virtual Access Technology Limited Controleur de trafic de reseau de donnees
WO2007066045A2 (fr) * 2005-12-09 2007-06-14 France Telecom Procede et dispositif d'emission de donnees en paquets
GB2440978B (en) * 2006-08-16 2012-01-04 Wireless Tech Solutions Llc Wireless communication system, apparatus for supporting data flow and methods therefor
US8477624B2 (en) * 2008-03-31 2013-07-02 Lenovo (Singapore) Pte. Ltd Apparatus, system, and method for managing network bandwidth

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0225880A2 *

Also Published As

Publication number Publication date
AU2001295307A1 (en) 2002-04-02
WO2002025880A2 (fr) 2002-03-28
CA2422919A1 (fr) 2002-03-28
WO2002025880A3 (fr) 2002-10-10

Similar Documents

Publication Publication Date Title
Balakrishnan et al. The congestion manager
US6584083B1 (en) Internet over satellite method
US6654344B1 (en) Method and system for controlling data flow in an internet over satellite connection
US20070008884A1 (en) Immediate ready implementation of virtually congestion free guarantedd service capable network
US6529477B1 (en) Internet over satellite system
US6934255B1 (en) Internet over satellite apparatus
US20030131079A1 (en) Performance enhancing proxy techniques for internet protocol traffic
US6460085B1 (en) Method and system for managing memory in an internet over satellite connection
JP3814678B2 (ja) サテライトを介するインターネット
EP1395014B1 (fr) Procédé de transmission de données en continue avec de segments de données à longeur variable
EP1240753A1 (fr) Procede de regulation de congestion dans un reseau commute par paquets
AU1050601A (en) Method and system for discarding and regenerating acknowledgment packets in ADSL communications
EP1107540A2 (fr) Système et procédé pour la communication de données
EP1393497B1 (fr) Plateforme de service double mode dans un systeme de communication par reseau
Wang et al. Use of TCP decoupling in improving TCP performance over wireless networks
US20060209687A1 (en) Communication rate control method and device
WO2002025880A2 (fr) Configuration dynamique du protocole tcp pour trafic voix/donnees a faible temps de latence
US20040100979A1 (en) Protocol performance using ACK filtering
US20060224769A1 (en) Method and transmitter for transmitting data packets
EP1505759B1 (fr) Procédé et dispositif de transmission/réception de données utilisant la couche de transport avec accusé de réception
CA2372023A1 (fr) Technique de regulation de surcharge dans un reseau a commutation par paquets
Cisco Configuring X.25 and X.3
Cisco Configuring X.25 and X.3
Cisco Configuring X.25 and X.3
Cisco Configuring X.25 and X.3

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030422

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20031001

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050611