Subject: Re: Doing ftp via multicast addresses.

From: [email-masked] (Mostafa Ammar)
Date: Thu, 15 Feb 1996 15:41:52 -0500 (EST)

>
>
> >Does anybody has experience in doing ftp using multicast
> >addresses i.e.
> 
> >If you want to ftp a file to 10 sites, can you use 
> >multicasting to send it to 10 different sites?
>
>no, no, no, no, no, no, no, no, no, no :-)
>
>FTP uses TCP
>TCP cannot use IP multicast - 
>
>1/ the n-1 multiple SYN ACKs generated from
>recipients of the SYN  after the first SYNACK  on connection setup cause 
>it to reset
>
>2/ the ACKs for outbound data packets will congest the link back to
>the sender....(actually, for 10 receivers, this might not be so bad in
>practice, but because of 1, you wont even get this far...)
>
>i.e. positive acknowledgement is not a good idea for one-to-many
>applications
>
> jon

Jon's points are all correct. Nevertheless, we have actually
built a system that does just that. It works well with a small number
of receivers but collapses (as you would expect) if there are too
many receievers. But sometimes all you need is reach a small number
of receivers.

The system we built puts a converter between TCP and IP multicast
to convert between the TCP one-to-one semantics and the IP multicast
semantics. We dubbed this the Single Connection Emulation (SCE)
Architecture. Multicast applications can now use TCP directly to
do reliable multicast.
Our purpose was not to build a highly scalable reliable multicast
service but instead to experiment with the conversion architecture
and prove its feasibliy. The byproduct, however, was a reasonable,
small scale reliable multicast protocol that can easily allow you
to do things like multicast FTP. We have also used it to build
a multicast web server.

You can find a description of the SCE architecture in:

Talpade, R., Ammar, M. H., ``Single Connection Emulation (SCE): An Architecture for
Providing a Reliable Multicast Transport Service,'' 
Proceedings of the IEEE International Conference on Distributed Computing
Systems, Vancouver, BC, Canada, June 1995. 

You can find this report and some discussion of what we built in 

http://www.cc.gatech.edu/computing/Telecomm/playground/SCE/outline.html

One problem is that our code (because it sits between TCP and IP)
runs in the kernel and therefore is not easily deployable.
RMP (referenced in Jon's note) runs in user space. 

Mostafa

=================================================================
Mostafa Ammar                        Phone:(404)894-3292
Associate Professor                  Fax:  (404)894-0272
College of Computing                 E-mail: [email-masked]
Georgia Institute of Technology
Atlanta, GA 30332
		   WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar
=================================================================

---

From: [email-masked] (Steve Zabele)
Date: Fri, 16 Feb 1996 11:28:13 -0500

>Kamal Dhaliwal writes:

We also have a "multicast ftp" capability (like evryone else, its called
"mftp") which does what you need. Our mftp uses RAMP (RFC 1458)  which sits
on top of IP/multicast. RAMP uses multicast for both transmission and
retransmission (or unicast retransmission if you like - your option) along
with NAK-based selective retransmit for error recovery and a simple flow
control scheme. Performance has been reasonably scalable so far. Our mftp
implementation is not "fully featured" as it has mostly been as a simple
test program for RAMP -- which we have primarily been using for WAN data
conferencing (CSCW) and WAN Distributed Interactive Simulation (DIS)
applications. However, if you are interested, give us a call.

(BTW - details on RAMP will appear  in the proceedings of InfoCom '96)

Steve