[Udpcast] Image Distribution Consistency

Alain Knaff alain.knaff at lll.lu
Sun Jun 15 20:59:12 CEST 2003


On Sunday 15 June 2003 20:31, Gianni Minetti wrote:
> Hi to everybody.
>
> I understand that udpcast guarantees  the integrity of the transmitted data
> through FEC redundancy  code model but how can one be assured , beside
> integrity,  also of consistency of the transmitted data, defining
> consistency as the property the all the hosts being part of the multicast
> group have received the data?


In its default mode (LAN), every "slice" is acknowledged by all hosts,
which allows the server to be sure that all data has been
received. If data has been missed, it is retransmitted.

If a receiver is _very_ slow to answer, or still hasn't got all
packets after the umpteenth retrial by the server, the server will
"drop" him, in order to allow the transmission to go on for the
others. This is useful for cases where one receiver is crashed. In
that case, the dropped receiver will miss all data transmited from
that point on (however, the timeout is several minutes...)

There is no CRC included at the application level, thus integrity need
to be enforced by the lower level protocols (IP, Ethernet). However,
in serveral years of operation of udpcast, there is no known incident
where data got corrupted during an udpcast transfer (on 100 Mbps or 10
Mbps Ethernet).


In FEC mode, there are no acknowledgements. In the event of packet
loss, the FEC packets allow to reconstruct any lost packet (if less
packets have been lost than there are FEC packets). If more packets
are lost than there are FEC packets, the same thing happens as with a
"dropped" receivers in LAN mode: the receiver misses all the rest of
the transmission. Hence it is important to tune the FEC parameters in
such a way as to cover the physical packet drop characteristics of the
medium used. These parameters can either be found out by trial and
error, or by probabilistic calculations.

In FEC mode as well, there is no CRC. FEC only recovers lost packets,
not corrupted packets. It relies on CRC's being implemented by the
lower level protocols. FEC mode has been used much less than LAN mode,
and hence I won't make any bold claim on how well this "no corruption"
hypothesis holds up in practice in FEC mode...


> I mean, if my multicasting model is composed of N host and I schedule to
> send a different file every T minutes, how can I detect the condition of  D
> hosts not  reachable for a time >T (tahr result in data copied only on N-D
> hosts)?
> Should I check the 'health'  of all my N hosts before to run udpcast using
> icmp?

If you have a return channel (such as on a LAN), I'd suggest not using
asynchronous mode. In that case, all slice of data needs to be
acknowledged before the next is send. If your hosts are only
unreachable for short amount of time (less than a minute), this should
work out ok. If more, the receivers could be dropped due to the
timeout mechanism.

If you have no return channel (such on a satellite transmission),
asynchronous FEC mode is appropriate. But in such situation, you
wouldn't have icmp either...


> For the application I've in mind it's very important to know what has or
> hasn't been delivered to whom so, I would like to encourage everyone who
> has had a similar problem or has some idea how to cope with.

It might be useful to implement some after the fact checking of file
reception (i.e. periodically all receivers are polled to send back a
list of files they received with their sizes; and if some have not
been received or are too short, retransmit them using udpcast)

>
> Thanks a lot in advance for your suggestions.
>
> Regerds,
>
> Gianni

Regards,

Alain




More information about the Udpcast mailing list