On Thu, Mar 11, 2010 at 02:00:41AM -0800, Svein Skogen wrote: > I can't help but keep wondering if not some sort of FEC wrapper > (optional of course) might solve both the "backup" and some of the > long-distance-transfer (where retransmissions really isn't wanted) > issues.
Retransmissions aren't really the problem, at least not until you're dealing with a very lossy path. Old-style TCP stop-and-go-back-N retransmit is the problem, and it gets worse when combined with large windows (needed on long fast links) and nagle slow-start. Modern TCP, particularly SACK, deals well with all that. Default configs that don't enable large windows and socket buffers sometimes still get in the way, but that's a once-off setup annoyance at worst. If you wan't to use FEC in the network transport, you need to avoid TCP (or use many small TCP parallel streams, which has its own issues). Then you'll have to re-solve many of the other requirements TCP solves in some other way (primarily, flow control so your sender doesn't outpace the link or receiver and wind up with more packets dropped than your FEC can recover). Stream FEC is of most interest in broad/multicast, where it's better for clients to reconstruct data than storm the sender with retransmit requests. There could be an interesting application in here for multi-site replication using multicast, avoiding duplication on the transmit path out of the source data centre. There would still need to be a wrapper around this to catch up for periods where a receiver was off-air, but it could be a useful traffic optimisation for the everyday distribution. -- Dan.
pgp9mEXNBoPIQ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
