Network Communication: Flow Control, Loss Detection, and Streaming, Study notes of Computer Science

Various issues related to network communication, including flow control, loss detection, and streaming. It covers topics such as hop-by-hop and end-to-end flow control, window and bucket methods, media access control, and traffic policing. The document also touches upon stream-oriented communication and qos specification.

Typology: Study notes

Pre 2010

Uploaded on 09/02/2009

koofers-user-mex
koofers-user-mex 🇺🇸

10 documents

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Communication Problems
Flow, loss, congestion, policing
Messages get lost due to several factors, including collisions, lack of
buffer space, lack of computing power, etc
To allow the flow of data at a good pace, the senders of data should be
sensitive to the amount of data that is getting through (throughput of
the network). From each sender’s perspective, the maximum
bandwidth the network provides should be the upper limit on the
amount of data to be transmitted. Does this work for real-time?
However, several senders at once may cause network congestion
The protocol being used must provide some means of detecting lost
messages (or packets) and of correcting present and future
Two types: hop-by-hop and end-to-end flow control and loss detection
and correction
Trade-offs?
Flow Control
Some methods are windows (sliding and jumping) and buckets
Windows count the number of packets in each window and refuse any
packets that exceed the number allowed in the window
Buckets have a (usually) constant rate of accepting packets. Any
packet in excess to that rate is not accepted (dropped)
pf3
pf4
pf5
pf8

Partial preview of the text

Download Network Communication: Flow Control, Loss Detection, and Streaming and more Study notes Computer Science in PDF only on Docsity!

Communication Problems

  • Flow, loss, congestion, policing
  • Messages get lost due to several factors, including collisions, lack of buffer space, lack of computing power, etc
  • To allow the flow of data at a good pace, the senders of data should be sensitive to the amount of data that is getting through (throughput of the network). From each sender’s perspective, the maximum bandwidth the network provides should be the upper limit on the amount of data to be transmitted. Does this work for real-time?
  • However, several senders at once may cause network congestion
  • The protocol being used must provide some means of detecting lost messages (or packets) and of correcting present and future
  • Two types: hop-by-hop and end-to-end flow control and loss detection and correction
  • Trade-offs? Flow Control
  • Some methods are windows (sliding and jumping) and buckets
  • Windows count the number of packets in each window and refuse any packets that exceed the number allowed in the window
  • Buckets have a (usually) constant rate of accepting packets. Any packet in excess to that rate is not accepted (dropped)

Flow Control

  • Flow control can be done with and without feedback from the net
  • If there is no feedback, the sender has to control the number of packets it will send according to some pre-established threshold
  • This scheme is often applied to implicit resource reservation used in many multimedia and real-time applications (due to the tight timing requirements, for example, video and audio, their synchronization, telephone delays or echoes, etc)
  • On the other hand, feedback can come on a hop-by-hop basis, or on an end-to-end basis.
  • Feedback can take several forms, for example the time for a packet to arrive to the destination (final or intermediate) plus the time for an ack to be received by the sender ( round trip delay)
  • Another example is the packets that arrive at a destination, or their ordering, for example a destination got packet n , but not yet packet n- k Media Access Control In LANs, usually the medium is shared among all Pes Therefore, there must be a way of detecting when it is safe to transmit, and after that, if the transmission was successful explicit reservation of the bandwidth and time to send implicit reservations for each PE in LAN (eg, token rings) hope and pray: put the packet in the network and wait for ack look, hope, and pray: attempt to send only if no other traffic on net Aside from collisions, the PE should be able to collect the bits from the network, put them into packets, put these into messages and give them to the user or forward them to the next hop (switch) Usually protocols implemented in software are the bottleneck in terms of performance (data transfer rates) Many new applications are taking the protocols to hardware with an improvement of a factor of 4-20 times their software counterparts

Data Streams a) A stream between two processes across a network. a) A stream directly between two devices. Data Streams

  • An example of multicasting a stream to several receivers.

Streams, flows and QoS

  • The Quality of Service (QoS) of an application is the “look and feel” of how the stream will flow
  • The QoS depends on two components:
    • Specification of the flow/stream
    • Implementation to satisfy the flow/stream specifications.
  • A flow specification encompasses
    • The rates at which the media is transmitted
    • How bursty the flow/stream is
    • How much error can there be (given a cost function, hopefully!)
  • The implementation depends on many, many factors
    • Common among all implementations is an enforcement of the specs Specifying QoS
  • QoS specification parameters for a Token Bucket model
  • Token bucket: the flow/stream is serviced when there are “credits”
  • Other schemes are also good, but different characteristics
  • Leaky buckets
  • Explicit real-time scheduler          μ !"$# % &')( *!+-, ./!!0!1" 2 !3 + 43 5 3 +7698;: <$+7< ( 23 +4!% &= (^323) > ( >?:@" ,< 6 2.@+43 #"A:B8 μC D$E F GHJIAK)L MON M?P (^) D QI$RTSAI UVL IAW4L X/Y[Z (^) μ \V] ^_ 1acbd efg7hTi@jlkbmd nod pmg (^) ]$]qd$rf qsbtqvu@d$g dwb ptf g \fx]zy{ hg (^) ]l\_ 1|i} (^) ] p {b^}]g-nd$g (^) ]zy{ hg (^) ] \~m\1]$^ _1|i} (^) ]{ b^}]g \fx]zy{ h€g (^) ]l\_ `‚d$rf qsbtq?g4nod p\qƒf (^) \\ fi/p[n„d$g (^) ] y{ h€g^ ]l\V~m\ ]$^ _ ”0•@–J‡V–)‹ —˜†J‡4‰ ™$—€‰ ‹$™Tšl›‚—• †œmžŸl — †‚‡ ˆŠ‰ ‹$†Œl†Ž‘/‰’‡V†“

Vnet: Pitt’s approach

  • V-net is a versatile network architecture [IEEE Transactions on Computers, Aug 2000]
  • Specification of both minimum data rate (mandatory traffic $), above minimum (optional traffic $$$), and bursty traffic
  • Use real-time scheduling techniques to be able to schedule streams:
    • EDF is earliest deadline first: if CPU utilization is less than 100% of the time, accept new stream
    • RMS is rate monotonic scheduling: if CPU utilization is less than n(21/n-1) , accept new stream
    • CPU utilization is sum of all process utilizations, which is Ci/Pi where Ci is the execution time of the process and Pi is the period f the process
  • Probabilistic acceptances are also possible, and price-based approaches should also be explored Added / Alternative protocols
  • Best Effort (some call is ‘hope and pray’ method):
    • Do as much as you can, and live with consequences
  • Fair Queueing or Processor sharing:
    • Define the “share” of each process
    • System to provide only that much service
    • How is it accomplished?
  • RSVP: ReSerVation Protocol
    • Soft-state protocol (refresh messages) allows for routes to be pinned.
    • Need to refresh routes at specific periodicity
    • Overhead is high if large groups or if many short-lived communications
  • Multicast Trees
    • Shared Trees (ST): one tree for all sources and destinations (minimum spanning tree, steiner tree problem)
    • Source-Specific Trees (SST): one tree per source.
    • Advantages and disadvantages?

Synchronization Mechanisms ( 1 )

  • Synchronization of data and of flows is a big problem, mainly due to the unpredictability of the computing systems we have today - Interrupts may disturb media continuity - Priority inversion may occur (high priority task blocked by low priority task) - Different flows should be synchronized
  • Application can do synchronization
  • Hardware can be used to help specially when the sync requirements are strict - Separate streams should be played within 30 microsecs Synchronization Mechanisms ( 2 )
  • Synchronization supported by high-level interfaces.
  • Middleware or specialized applications (or layers) multiplex all substreams into a single stream, and demultiplex at the receiver.
  • Synchronization is handled at multiplexing/ demultiplexing point
  • Example: MPEG