Impact of Satellite Networks on Transport Layer Protocols

1,793 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,793
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
58
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • one or more TCP segments may not reach the otherend of the connection, and TCP uses timeout mechanisms to detect those missing segments.
  • allows routers to inform TCP senders about imminentcongestion without dropping segments
  • Impact of Satellite Networks on Transport Layer Protocols

    1. 1. Satellite Networking Principles and Protocols;Impact of Satellite Networks on Transport Layer Protocols<br />Advisor: Dr. Nemaney pour<br />Prepared By: Reza Ghanbari Maman<br />December 2010<br />
    2. 2. Outline<br />Introduction<br />TCP performance Analysis<br />Slow Start Enhancement<br />Loss recovery enhancement<br />Enhancements using interruptive mechanisms<br />Voice over IP<br />Real-time transport protocol<br />
    3. 3. Introduction<br />Transport Communication Protocol<br />The end to end protocol between processes in different hosts across internet networks.<br />It is transparent to the internet.<br />The most challenging task is to provide reliable and efficient transmission services without knowing anything about application above it or anything about the internet below it.<br />Application<br />Host parameters<br />Configurations<br />Channel <br />TCP control<br />
    4. 4. Introduction<br />Application Characteristics<br />Remote login<br />File transfer<br />World wide web and e-mail<br />Client and server host parameters<br />Process power<br />Buffer sizes<br />Speeds of NIC’s<br />Round Trip Time (RTT)<br />Satellite network configurations<br />Assumption : <br />Constraints: Long delay, Errors, Limited bandwidth, etc.<br />Access networks and internetworking units are capable of dealing with traffic flows<br />Application<br />Host Parameters<br />Configurations<br />Channel <br />TCP control<br />
    5. 5. Introduction<br />Application<br />Host Parameters<br />Configurations(Cont.)<br />Channel <br />TCP control<br />Asymmetric satellite networks<br />Forward direction : From satellite gateway station to user stations<br />Return direction: User stations to satellite gateway station<br />Data rate in the forward direction is larger than the return direction, because of limits on the transmission power and the antenna size at different satellite earth stations <br />Receive-only broadcasting satellite systems:<br />Unidirectional <br />It can be used as non-satellite return path<br />The nature of most TCP traffic is asymmetric with data flowing in one direction and acknowledgements in the opposite direction<br />DVB-S, DVB-RCS and VSAT satellite networks<br />
    6. 6. Introduction<br />Application<br />Host Parameters<br />Configurations(Cont.)<br />Channel <br />TCP control<br />Satellite link as last hop<br />Provide directly service as opposed to satellite links located in the middle of a network, may allow for specialized design of protocols used over the last hop. <br />Providers use;<br />Satellite link as shared high-speed downlink to users with a lower speed<br />Non-shared terrestrial link as a return link for requests and ACK’s<br />Hybrid satellite networks<br />Typical configuration<br />Satellite links <br />Locate at any point in the network topology<br />Act as another link between two gateways<br />Connection may be sent over terrestrial links (including terrestrial wireless), as well as satellite links<br />
    7. 7. Introduction<br />Application<br />Host Parameters<br />Configurations(Cont.)<br />Channel <br />TCP control<br />Point-to-point satellite networks<br />Pure Configuration<br />Only hop is over the satellite link<br />Multiple satellite hops<br />Network traffic may traverse multiple hops between source and destination which aggravates the satellite characteristics<br />Generic problem because of many more constraints due to long delay, error and bandwidth<br />Constellation satellite networks<br />Without Inter Satellite Links<br />Wide coverage is achieved by multiple satellite hops<br />With Inter Satellite Links<br />wide coverage is achieved by ISL<br />Problem:<br />Dynamic network routing <br />Variable end-to-end delay<br />
    8. 8. Introduction<br />Application<br />Host Parameters<br />Configurations<br />Channel <br />TCP control<br />Internet consists of various topologies, bandwidth, delays and packet sizes<br />TCP <br />defined in RFC793, RFC1122, RFC1323<br />It is a byte stream (Not a message stream)<br />Message boundaries are not end to end preserved<br />It is full-duplex connection and point to point<br />It does not support multicasting or broadcasting<br />The sending and receiving entities exchange data in the form of segments<br />Segment of TCP<br />Fixed 20-bytes header followed by zero or more data bytes<br />Size limitations<br />Each segment fit into 65,535 bytes IP/v4 payload and Maximum Transfer Unit (MTU)<br />
    9. 9. Introduction<br />Application<br />Host Parameters<br />Configurations<br />Channel (Cont.)<br />TCP control<br />TCP and satellite channel characteristics<br />Long Round Trip Time (RTT)<br />Due to the propagation delay<br />Determination of successfully received at the final destination may take a long time for a TCP sender<br />Large Delay Bandwidth product<br />Due to the bottleneck link<br />It defines the amount of data a protocol should have data that has been transmitted but not yet acknowledged (called In-Flight)<br />Variable Round Trip Times<br />It is a variable propagation delay to and from the satellite in LEO constellations<br />Affects to Retransmission Time Out (RTO)<br />Alternate connectivity<br />This may cause packet loss in non-GSO satellite orbit configurations <br />
    10. 10. Introduction<br />Application<br />Host Parameters<br />Configurations<br />Channel (Cont.)<br />TCP control<br />TCP and satellite channel characteristics (Cont.)<br />Asymmetric use<br />Due to the expense of the equipment used to send data to satellites<br />Situated that the uplink has less available capacity than the downlink for return channel<br />May have an impact on TCP performance<br />Transmission errors<br />Bit Error Rate (BER) <br />Satellite channels higher than typical terrestrial networks<br />TCP assumes<br />network congestion <br />encloses to all packet drops<br />Moderated by reduction of window size<br />Avoided by assigning that the drop was due to it<br />
    11. 11. Introduction<br />Application<br />Host Parameters<br />Configurations<br />Channel<br />TCP control<br />TCP Control<br />Flow control<br />To ensure <br />the transmitted data is at a rate consistent<br />Shared capacity of a link among the connections using it<br />Result<br />Most throughput issues are exhausted<br />Congestion Control<br />Used to avoid generating network traffic<br />Mechanisms <br />Slow start<br />Congestion avoidance<br />Fast retransmit before RTO expires<br />Fast recovery to avoid slow start<br />
    12. 12. Introduction<br />Application<br />Host Parameters<br />Configurations<br />Channel<br />TCP control (Cont.)<br />TCP Control<br />Characteristics<br />Congestion Window (cwnd)<br />Higher priority to inject into the network before receiving an ACK<br />The value is limited to the receiver’s advertised window size<br />Slow Start Threshold (ssthresh)<br />If cwnd < ssthresh then the Slow-Start Algorithm is used to increase the value of cwnd<br />If cwnd >= ssthresh then Congestion Avoidance Algorithm is used <br />The initial value is the receiver’s advertised window size and is set when congestion is detected<br />Negative impact on the performance <br />Because of slow probe to the network for additional capacity and wastes bandwidth<br />It is true over long-delay satellite channels <br />because of more time consumption to obtain feedback from the receiver<br />
    13. 13. TCP performance analysis<br />First Transmission<br />Slow Start Trans.<br />Congestion Avoidance Trans.<br />Usage of satellite link as satellite networks <br />Expensive <br />Time consumption to implement<br />Analysis and calculation of bandwidth utilization over a point-to-point satellite network as;<br />First TCP Transmission<br />TCP Transmission in Slow Start Stage<br />TCP Transmission in Congestion Avoidance Stage<br />
    14. 14. First Transmission<br />Slow Start Trans.<br />Congestion Avoidance Trans.<br />: Data to transmit<br />: Propagation Delay<br />: Bandwidth capacity<br />: Utilization<br />First TCP Transmission<br />Bandwidth Utilization<br />Complete data transmission<br />TCP transmission in slow start Stage<br />Let where n is the total number of RTT<br />Bandwidth Utilization<br />TCP performance analysis<br />
    15. 15. First Transmission<br />Slow Start Trans.(Cont.)<br />Congestion Avoidance Trans.<br />: Data to transmit<br />: Propagation Delay<br />: Bandwidth capacity<br />: Utilization<br />TCP transmission in slow start Stage(Cont.)<br />Complete data transmission<br />General Transmitted date size where 0 ≤  < 1<br />Link Utilization<br />General Complete data transmission<br />TCP performance analysis<br />
    16. 16. First Transmission<br />Slow Start Trans.<br />Congestion Avoidance Trans.<br />TCP transmission in congestion avoidance stage<br />Transmitted data size where m is maximum size <br />Link Utilization where 0 ≤ β < 1<br />Window Size<br />TCP performance analysis<br />
    17. 17. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger initial window<br />Slow-Start Termination<br />Optimization of TCP performance <br />Major problem of TCP<br />Unknown total data size<br />Unknown available bandwidth<br />Unknown carry process of TCP segment<br />Slow-start enhancement<br />
    18. 18. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger initial window<br />Slow-Start Termination<br />Optimization of TCP performance (Cont.)<br />Rules and parameters<br />Increase minimum segment size of <br />Limitations<br />Slow-Start threshold<br />Congestion window size<br />Receiver buffer size<br />Improve Slow-Start algorithm<br />Limitation<br />Slow transmission<br />Improve ACK<br />Limitation<br />Buffer Space<br />Detect packet loss due to transmission error<br />Limitation<br />ACKs transmitted at different paths<br />Improve congestion avoidance mechanism<br />Limitation<br />Slow transmission<br />Slow-start enhancement<br />
    19. 19. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger initial window<br />Slow-Start Termination<br />TCP enhancement techniques<br />For short request/response traffic, utilization affected by<br />Connection set-up <br />Using three-way handshake (with Synchronization number-SYN)<br />Requiring 1 to 1.5 RTT<br />Using TCP extensions to eliminate<br />Connection close-down time<br />Bandwidth utilization <br />At small data size transactions<br />Very low<br />Improvement <br />Ability to share the same bandwidth<br />Slow-start enhancement<br />
    20. 20. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger initial window<br />Slow-Start Termination<br />Slow start and delayed acknowledgement (ACK)<br />Slow-Start algorithm <br />Used by TCP to increase the size of congestion window <br />Used to making safe against transmitting an inappropriate amount of data into the network when the connection starts up<br />Waste network capacity due to large DB product<br />Delayed ACK<br />receivers refrain from acknowledging every incoming data segment<br />Every second full-sized segment is acknowledged<br />If it does not arrive within a timeout, then an ACK must be generated (Timeout <500 ms) <br />by increasing of cwnd size, the number of ACKs slows the cwnd growth rate may decrease <br />a second segment must arrive before an ACK is sent<br />Note: The receiver is always forced to wait for the delayed ACK timer to expire before acknowledging the first segment which also increases the transfer time<br />Slow-start enhancement<br />
    21. 21. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger Initial Window<br />Slow-Start Termination<br />Larger Initial Window<br />By increasing the initial value of cwnd<br />More packets are sent during the first RTT of data transmission, <br />More ACKs, allowing the congestion window to open more rapidly. <br />By sending at least two segments initially<br />First segment does not need to wait for the delayed ACK timer to expire as is the case when the initial size of cwnd is one segment<br />Using a fixed larger initial congestion window <br />decreases the impact of a long RTT on transfer time<br />A mechanism is required to limit the effect of these bursts. <br />Using delayed ACKs only <br />Offers an alternative way to immediately ACK the first segment of a transfer<br />Opens the congestion window more rapidly<br />Note: The value of cwnd saves the number of RTT and a delayed ACK timeout<br />Slow-start enhancement<br />
    22. 22. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger Initial Window<br />Slow-Start Termination<br />Termination of Slow Start<br />When TCP detects congestion<br />When the size of cwnd reaches the size of the receiver’s advertised window<br />When cwndgrows beyond a certain size<br />When the cwnd reaches the reduced ssthresh<br />Notes:<br />TCP ends slow start and begins using the congestion avoidance algorithm when it reaches the slow-start threshold (ssthresh)<br />Terminating at the right time is useful to avoid overflowing the network <br />Avoiding multiple dropped segments<br />Slow-start enhancement<br />
    23. 23. TCP for trans.<br />Slow-Start & Delayed ACK<br />Larger Initial Window<br />Slow-Start Termination(Cont.)<br />Termination of Slow Start (Cont.)<br />Packet-pair algorithm <br />observes the spacing between the first few returning ACKs <br />Determines the bandwidth of the bottleneck link <br />Together with the measured RTT<br />Determining DB product is determined <br />Setting ssthresh the value<br />Slow-start enhancement<br />
    24. 24. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />Loss Recovery Enhancement<br />Satellite paths <br />Higher error rates than terrestrial lines<br />Causing errors in data transmissions to be retransmitted<br />TCP typically interprets loss as a sign of congestion and goes back into the slow start<br />Prevents TCP going to slow start unnecessarily when data segments get lost due to error<br />NewReno TCP algorithm is used ,but independent from the availability of Selective ACK<br />Note: we need to reduce the error rate to a level acceptable to TCP or find TCP knowing that datagram loss is due to transmission errors, not congestion<br />Loss recovery enhancement<br />
    25. 25. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />Fast Retransmission and Fast Recovery<br />TCP segments may not reach the other end connection, and TCP uses timeout mechanisms to detect those missing segments, hence TCP assumes that segments are dropped due to network congestion<br />Result: ssthresh being set to half the current value of cwnd and its size is being reduced to the size of one TCP segment<br />Avoids the unnecessary process of backward process of Slow Start when a segment fails to reach the intended destination<br />Detects the loss of segments by using duplication of ACKs <br />Used to retransmit the missing data segment<br />Result: TCP can use to resume the normal transmission process via the congestion avoidance phase instead of slow start as before<br />Loss recovery enhancement<br />
    26. 26. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />Selective Acknowledgement<br />When multiple segments are lost within a single transmission window, TCP performs poorly<br />Limitation<br />TCP can only learn of a missing segment per RTT<br />Lack of cumulative acknowledgements<br />Reduction of TCP throughout <br />Improves TCP performance<br />Identifies missing TCP segments and retransmits within a single RTT<br />Note:Due to occasional high bit-error rates (BER) of the channel, the sender is notified about which segments have not been received and need to be retransmitted by received sequence numbers<br />Loss recovery enhancement<br />
    27. 27. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />SACK based enhancement mechanisms<br />Algorithm starts after Fast Retransmit triggers the resending of a segment<br />Algorithm reduces cwnd into half of the size when a loss is detected<br />Algorithm keeps a PIPE variable<br />Which is an estimate of the number of outstanding segments <br />Which is decremented by one segment for each duplicate ACK that arrives with new SACK information<br />Which is incremented by one for each new or retransmitted segment sent<br />Algorithm recovers multiple segment losses in a window of data within one RTT of loss detection<br />Loss recovery enhancement<br />
    28. 28. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />ACK congestion control<br />In high asymmetric networks (VSAT)<br />low-speed return link on a high-speed forward link<br />If a terrestrial modem link is used as a reverse link, ACK congestion as the speed of the forward link is increased<br />The flow of ACKs can be restricted on the low-speed link <br />by the bandwidth of the link<br />by the queue length of the router<br />Note: The Current congestion control mechanisms are aimed at controlling the flow of data segments, but do not affect the flow of ACKs<br />Loss recovery enhancement<br />
    29. 29. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />ACK Filtering<br />It is designed <br />to address the same ACK congestion effects<br />to operate without host modifications<br />It takes advantage of the cumulative ACK structure of TCP<br />It is implemented by the modified bottleneck router in the reverse direction<br />It is used to produce significant sender bursts by modification of Sender Adaption (SA)<br />Explicit Congestion Notification (ECN)<br />It allows routers to inform TCP senders about imminent congestion without dropping segments<br />Loss recovery enhancement<br />
    30. 30. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification (Cont.)<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />Explicit Congestion Notification (Cont.)<br />Forms<br />Backward ECN (BECN)<br />BECN router transmits messages directly to the data originator informing it of congestion<br />IP routers can accomplish this with an ICMP source quench message<br />The arrival of a BECN signal may or may not mean that a TCP data segment has been dropped, but it is a clear indication that the TCP sender should reduce the value of cwnd<br />Forward ECN (FECN)<br />FECN routers mark data segments with a special tag when congestion is imminent, but forward the data segment<br />The data receiver then shows the congestion information back to the sender in the ACK packet<br />Loss recovery enhancement<br />
    31. 31. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification (Cont.)<br />Detecting corruption loss<br />Congestion avoidance enhancement<br />Detecting Corruption Loss<br />Corruption Loss<br />TCP should retransmit the damaged segment as soon as its loss is detected; there is no need for TCP to adjust its congestion window i.e. it should immediately reduce its congestion window to avoid making the congestion worse<br />May be detected using the fast retransmit algorithm or by the expiration of TCP’s retransmission timer<br />Problem<br />It is more common than on terrestrial networks<br />Solution<br />Adding Forward Error Correction (FEC) to the data but it can not be universally applied<br />Corrupted TCP segment <br />Dropped by intervening routers <br />Survive without detection until it arrives at the TCP receiving host<br />Does not indicate congestion<br />Loss recovery enhancement<br />
    32. 32. Fast re-trans. & fast recovery<br />Selective ACK<br />SACK based enhancement<br />ACK congestion control<br />ACK filtering<br />Explicit congestion notification (Cont.)<br />Detecting corruption loss<br />Congestion Avoidance Enhancement<br />Congestion avoidance enhancement<br />In the absence of loss, the TCP sender adds approximately one segment to its congestion window during each RTT<br />Problem<br />Unfair sharing of bandwidth when multiple connections with different RTTs traverse the same bottleneck link, with the long RTT connections<br />Solution<br />Deployment of fair queuing and TCP-friendly buffer management in network routers<br />Policy changes<br />The “constant-rate” increase policy attempts to equalize the rate at which TCP senders increase their sending rate during congestion avoidance<br />The “increase-by-K” policy can be selectively used by long RTT connections in a heterogeneous environment<br />Loss recovery enhancement<br />
    33. 33. TCP Spoofing<br />Cascading or Split TCP<br />Perfect Solution<br />Enhancements for satellite networks using interruptive mechanisms<br />Interruptive Mechanism<br />Enhancements using interruptive mechanisms<br />
    34. 34. TCP Spoofing<br />Cascading or Split TCP<br />Perfect Solution<br />TCP Spoofing<br />Helps to improve TCP performance over satellite<br />Problem<br />The router must do a considerable amount of work after it sends an acknowledgement<br />Spoofing requires symmetric paths: <br />the data and acknowledgements must flow along the same path through the router<br />Spoofing is vulnerable to unexpected failures<br />If a path changes or the router crashes, data may be lost<br />Spoofing does not work if the data in the IP datagram are encrypted <br />Because the router will be unable to read the TCP header<br />Enhancements using interruptive mechanisms<br />
    35. 35. TCP Spoofing<br />Cascading or Split TCP<br />Perfect Solutions<br />Cascading TCP or Split TCP<br />TCP running over the satellite link can be modified, with knowledge of the satellite’s properties, to run faster<br />Because each TCP connection is terminated, cascading TCP is not vulnerable to asymmetric paths<br />Perfect Solutions <br />Satellite Networking<br />Should be able to meet the requirements of user applications, <br />Takes into account the characteristics of data traffic<br />Makes full use of network resources<br />Enhancements using interruptive mechanisms<br />
    36. 36. TCP Spoofing<br />Cascading or Split TCP<br />Perfect Solutions(Cont.)<br />Perfect Solutions (Cont.)<br />Solutions<br />Based on the enhancement of existing TCP mechanisms have reached their limits as <br />No knowledge about applications <br />No knowledge about networks and hosts<br />Finding new techniques to achieve multi-layer and cross-layer optimization of protocol architecture<br />Enhancements using interruptive mechanisms<br />
    37. 37. TCP Spoofing<br />Cascading or Split TCP<br />Perfect Solutions(Cont.)<br />Perfect Solutions (Cont.)<br />Solutions<br />Based on the enhancement of existing TCP mechanisms have reached their limits as <br />No knowledge about applications <br />No knowledge about networks and hosts<br />Finding new techniques to achieve multi-layer and cross-layer optimization of protocol architecture<br />Enhancements using interruptive mechanisms<br />
    38. 38. Gateway Decomposition<br />Protocols<br />Gatekeepers<br />MMC <br />Conference Control<br />Based on RTP, IP telephony is becoming a mainstream application moving away from proprietary solutions to standards based solutions, providing QoS comparable to the PSTN and providing transparent interoperability of the IP and PSTN networks<br />Gateway Decomposition<br />The signaling gateway is responsible for signaling between end users on either network. On the PSTN side, an IP signaling protocol such as SIP or H.323, and transported across the IP network<br />SAP <br />Announces the session<br />SDP <br />Describes the call (or session)<br />Voice over IP<br />
    39. 39. Gateway Decomposition<br />Protocols<br />Gatekeepers<br />MMC <br />Conference Control<br />Gateway Decomposition (Cont.)<br />Media gateway<br />Data, video and audio stream transfer responsibility once a call is set up<br />On the PSTN side, media transport is by PCM-encoded data on TDM streams; <br />On the IP network side, media transport is by PCM-encoded data on RTP/UDP<br />Media gateway controller <br />Controls one or more media gateways<br />Protocols<br />H.323 (s)<br />Introduced by ITU<br />Provide multimedia capability over the Internet<br />RTP,RTSP, RTCP, Megaco, SIP and SDP<br />Introduced by IETF<br />Provide the foundation for standards based IP telephony<br />Voice over IP<br />
    40. 40. Gateway Decomposition<br />Protocols<br />Gatekeepers<br />MMC<br />Conference Control<br />Gatekeepers<br />Are responsible for addressing, authorization and authentication of terminal and gateways, bandwidth management, accounting, billing and charging<br />Provide call-routing services<br />Note: Terminal is a PC or stand-alone device running multimedia applications. Multipoint control units (MCU) provide support for conferences of three or more terminals.<br />Voice over IP<br />
    41. 41. Gateway Decomposition<br />Protocols<br />Gatekeepers<br />MMC<br />Conference Control<br />Multimedia conferencing (MMC)<br />One of the typical example applications based on IP multicast<br />Components<br />Voice provides packet audio in time slices, numerous audio-coding schemes, redundant audio for repair, unicast or multicast, configurable data rates<br />Video provides packet video in frames, numerous video-coding schemes, unicast or multicast, configurable data rates<br />Network Text Editor can be used for message exchanges<br />Whiteboard can be used for free-hand drawing<br />Voice over IP<br />
    42. 42. Gateway Decomposition<br />Protocols<br />Gatekeepers<br />MMC<br />Conference Control<br />Conference control<br />provides functions and mechanisms for users to control how to organize, manage and control a conference<br />Control function<br />Floor control: Who speaks? Chairman control? Distributed control?<br />Loose control: One person speaks, grabs channel<br />Strict control: Application specific, e.g. lecture<br />Resource reservation: Bandwidth requirement and quality of the conference<br />Per-flow reservation: Audio only, video only, audio and video<br />Voice over IP<br />
    43. 43. Real-time transport protocol<br />Internet protocols<br />Specified for the transmission of raw data between computer systems<br />The emergence of modern applications and mainly those based on real-time voice and video present new requirements to the IP protocol suite<br />Products support streaming audio, streaming video and audio-video conferencing<br />Basic of RTP<br />Real time transport protocol<br />Provides end-to-end network transport functions suitable for applications transmitting real-time data.<br />RTP does not<br />Address resource reservation<br />Guarantee QoS for real-time services<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    44. 44. Basic of RTP(Cont.)<br />RTCP(real-time transport control protocol):<br />Allows monitoring of the data delivery in a manner scalable to large multicast networks<br />Provides minimal control and identification functionality<br />Applications run RTP on top of UDP:<br />Make use of its multiplexing and checksum services.<br />There are two closely linked parts:<br />RTP, to carry data that has real-time properties<br />RTCP, to monitor the quality of service and to convey information about the participants in an ongoing session<br />Real-time transport protocol<br />Basic of RTP(Cont.)<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    45. 45. Basic of RTP(Cont.)<br />Property<br />ability of one party to signal to one or more other parties and initiate a call<br />Session Invitation Protocol<br />a client-server protocol that enables peer users to establish a virtual connection between them and then refers to a RTP session carrying a single media type.<br />Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services<br />Real-time transport protocol<br />Basic of RTP(Cont.)<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />IP header<br />UDP header<br />RTP header<br />Data<br />
    46. 46. Basic of RTP(Cont.)<br />Components<br />End system<br />An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets<br />Mixer<br />An intermediate system that receives RTP packets from one or more sources combines the packets in some manner and then forwards a new RTP packet<br />Translator<br />An intermediate system that forwards RTP packets with their synchronization source identifier intact<br />Monitor<br />An application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current QoS for distribution monitoring, fault diagnosis and long-term statistics<br />Real-time transport protocol<br />Basic of RTP(Cont.)<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    47. 47. Basic of RTP(Cont.)<br />RTP header format<br />V 2-bits, version number (=2)<br />P 1-bit indicates padding<br />X 1-bit indicates extension header present<br />CC 4-bits, Number of CSRCs (CRSC count)<br />M 1-bit, profile specific marker<br />PT 7-bits, payload type, profile specific <br />SSRC synchronization source<br />CSRC contributing source<br />Timestamp has profile/flow-specific units<br />Real-time transport protocol<br />Basic of RTP(Cont.)<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    48. 48. RTP control protocol<br />Based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets<br />Performance functions<br />Primary function provides feedback on the quality of the data distribution<br />RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME<br />The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants<br />Optional function is to convey minimal session control information<br />Real-time transport protocol<br />Basic of RTP<br />RTP Control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    49. 49. Sender report (SR) packets<br />The first section (header) consists of the following fields.<br />Version (V)<br />Padding (P)<br />Reception report count (RC)<br />Packet type (PT)<br />Length<br />SSRC<br />The second section, the sender information, is 20 octets long and is present in every sender report packet.<br />NTP timestamp<br />RTP timestamp<br />Sender’s octet count<br />The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report.<br />Fraction lost<br />Cumulative number of packets lost<br />Extended highest sequence number received<br />Inter-arrival jitter<br />Last SR timestamp (LSR)<br />Delay since last SR (DLSR)<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    50. 50. Receiver report (RR) packets<br />The format of the receiver report (RR) packet<br />the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted<br />The same as SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted<br />Source description (SDES) RTCP packet<br />SDES packet<br />A three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk.<br />Chunk<br />Consists of an SSRC/CSRC identifier which carry information about the SSRC/CSRC<br />Starts on a 32-bit boundary<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    51. 51. Source description (SDES) RTCP packet(Cont.)<br />Item<br />Consists of an eight-bit type field describing the length of the text and the text itself.<br />System sends one SDES packet containing its own source identifier<br />Mixer sends one SDES packet containing a chunk for each contributing source from which is receiving SDES information or multiple complete SDES packets<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet(Cont.)<br />SAP & SIP protocols for SI<br />SDS<br />
    52. 52. SAP and SIP protocols for session initiations<br />Session Announcement Protocol (SAP)<br />Session creator merely multicasts packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place<br />Gets a little more complex when we take security and caching into account<br />Session Initiation Protocol (SIP)<br />Works like making a telephone call<br />Finds the person you are trying to reach and causes their phone to ring<br />Able to call traditional telephone numbers<br />Users may move to a different location<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    53. 53. SAP and SIP protocols for session initiations(Cont.)<br />A typical SIP call of initiate and terminate session<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI(Cont.)<br />SDS<br />
    54. 54. SAP and SIP protocols for session initiations(Cont.)<br />A typical SIP call using a redirect server and location server<br />A typical SIP call using a proxy server and location server<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI(Cont.)<br />SDS<br />
    55. 55. Session directory service (SDS)<br />Multicast services growing and leading applications to some navigation difficulties<br />Creation of a session directory service<br />Functions<br />A user creating a conference needs to choose a multicast address that is not in use<br />By allocating addresses with respect to a Pseudo-Random strategy<br />Multicasting the session information out and if it detects a clash from an existing SA, it changes its allocation<br />Users need to know what conferences there are on the multicast backbone (Mbone), what multicast addresses they are using, and what media are in use on them<br />Real-time transport protocol<br />Basic of RTP<br />RTP control protocol<br />Sender Report<br />Receiver Report <br />SDES-RTCP packet<br />SAP & SIP protocols for SI<br />SDS<br />
    56. 56. Thanks <br />Any Question?<br />

    ×