Re: UPD better than TCP in streaming video/audio ?

From: Puzzolino (puzzolino77_at_libero.it)
Date: 12/09/04 

Date: Thu, 09 Dec 2004 16:47:18 GMT

Alun Jones [MSFT] wrote:
> The key is not so much that one outperforms the other (because if that
were
> all that's at stake, nobody would bother with the lower-performance
> protocol.
>
> UDP gains speed over TCP because it carries no information that would
allow
> you to determine the order that data was sent in, and because it has no
> handling for lost data - not only doesn't it retry packets that got lost
> along the way, it doesn't even know that packets were lost.
>
> This makes it useful for protocols where out-of-order and lost or
duplicated
> packets are not a problem.
>
> TCP, on the other hand, carries sequence information, and uses
> acknowledgements to allow a sender to re-send any data that is not
received
> (and acknowledged) in a timely manner. Thus, TCP is a 'reliable'
protocol -
> it takes measures to ensure that the data gets there.
>
> This makes it useful for protocols where speed is less of a problem than
the
> importance of data reaching its destination intact and in order.
>
> So, for instance, if you're transmitting a file, you need all the data to
> get to the receiver. TCP is great for that - although the file doesn't
> necessarily have to arrive in sequence, it has to be assembled into
> sequence, and you have to be able to tell whether all the data has been
> received or not, and the simplest solution to that problem is not to allow
> byte N to be written until after byte N-1 has.
>
> If you're transmitting your location, however, you're more likely to care
> about where you are right now, rather than a detailed plot of everywhere
you
> have been - a half a second or so of missing data is not likely to lead to
> you becoming lost, especially if some of the data is getting through to
you.
>
> Streaming media is a classic example of "don't care if some of the data
> doesn't get there", which is perfect for UDP.
>
> But if you're downloading a movie to burn onto a DVD-R for later viewing,
> you want all the bits, so that there aren't any skips in the sound or
> picture, and so that you don't get a degradation in picture or sound
> quality. Such an application would do best to use TCP.
>
> Every so often, people come up with the idea of taking UDP because it's
> faster than TCP, and forget to take into consideration its lack of
> reliability. Then they realise that their application requires
reliability,
> and they add on features to support it. What they end up with is a
rewrite
> of TCP that has few of the features, little of the clever thinking, and is
> slower and more network-heavy.
>
> Finally, there's the possibility of multicast data - for instance, a live
> broadcast from a radio station on the Internet. This would be a great use
> of multicast UDP, because a) it's streaming media, and occasional
lossiness
> is fine, and b) multicasting it would mean that at most one copy of each
> datagram would traverse each link along the path between the radio station
> and its listeners, significantly reducing the traffic cost of popular
> stations (and adding almost nothing to the traffic cost of stations with
> only one person listening). Sadly ISPs have been reluctant to allow
> multicast traffic, and it's been difficult to implement multicast on an
> Internet-wide basis.
>
> Alun.
> ~~~~
> --
> Software Design Engineer, Internet Information Server (FTP)
> This posting is provided "AS IS" with no warranties, and confers no
rights.

Hi Alun,
thanks a lot for your long reply.
The more I work on it, the more I find limitations on the use of UDP: among
all, the maximum size of UDP packets and the use of compression on video
streams that makes consequent packets strictly dependant on each other (this
becomes a problem when packets get lost).
What do you think ?

Relevant Pages

  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Old SUN NFS performance papers.
    ... > also just generally a good idea, since UDP frags act as a fixed ... > you may be copying all your packets over again ), ... With TCP, you ... >> FreeBSD NFS servers, and therefore always looking for tweaks and nobs ...
    (freebsd-performance)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: UDP vs TCP
    ... I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. ... TCP for instance will break up a large packet into smaller ... > into the packets and then the receiving app would have to read ...
    (microsoft.public.vb.enterprise)
  • Re: help/advice regarding multicasting
    ... But that in TCP, and if you want it in UDP you have to add reliability to ... Now one way to do it is by multicast. ... packet and all the PC's that will catch that packet will join the ...
    (microsoft.public.win32.programmer.networks)