headers
Lorenzo Vicisano | 2 Mar 2005 18:56
Picon
Favicon

Re: no meeting at the Minneapolis IETF

Mark,

> I did not see the WG last call for TFMCC, probably because
> at some point my rmt email subscription stopped working.
> 
> My laboratory is making active use of TFMCC. We have
> identified to the TFMCC authors some cases where we
> believe it does not come adequately close to providing
> for performance that is fair to TCP. This is based on
> extensive studies using ns2 models. We'll be happy to
> continue to work with the TFMCC authors on this. I would
> question taking TFMCC forward until this issue is resolved.

thanks for taking the time to provide feedback. Could you
please coordinate with the TFMCC authors to address this and
let us know ?

> I will be in Minneapolis and could meet with you on this
> even though the RMT slot has been cancelled.

I will be there too.

	Lorenzo

> 
> Mark
> 
> On Wed, 23 Feb 2005, Lorenzo Vicisano wrote:
> 
> > All,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Pullen | 2 Mar 2005 21:05
Picon

Re: no meeting at the Minneapolis IETF

Lorenzo,

Coordination with the TFMCC authors is ongoing. We have
been exchanging emails since last July. Because we are
all busy, it takes a while to turn them around, but the
process continues between Joerg Widmer and myself. We
believe the TFMCC approach is fundamentally sound, but it
needs some more work if the results are to come within
a factor of two of actual TCP performance.

See you in Minneapolis.

Mark

On Wed, 2 Mar 2005, Lorenzo Vicisano wrote:

> Mark,
>
> > I did not see the WG last call for TFMCC, probably because
> > at some point my rmt email subscription stopped working.
> >
> > My laboratory is making active use of TFMCC. We have
> > identified to the TFMCC authors some cases where we
> > believe it does not come adequately close to providing
> > for performance that is fair to TCP. This is based on
> > extensive studies using ns2 models. We'll be happy to
> > continue to work with the TFMCC authors on this. I would
> > question taking TFMCC forward until this issue is resolved.
>
> thanks for taking the time to provide feedback. Could you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco Tana | 14 Mar 2005 12:16
Picon

reliable multicast transport via satellite

Dear all,
could you kindly report about IETF/RMT-WG point of view about reliable 
multicast transport via satellite?
I am working on this topic, I found many protocols in literature but no 
IETF RFC/drafts at all! I noticed that MFTP proposal has expired...
Which is the right direction to investigate? Particularly wrt reliable 
bulk data transfer with wired feedback channels?
Sincerely grateful
-Marco
--

-- 
"Be liberal in what you accept, and conservative in what you send."
Jon Postel - Internet Pioneer
___________________________________________________________________

Marco Tana
Center for Advanced Computational Technologies
Distretto Tecnologico/ISUFI - University of Lecce
s.p. Lecce Arnesano - 73100 Lecce - ITALY
Voice 0039.0832.298122
Fax   0039.0832.297279
e-mail marco.tana <at> unile.it
___________________________________________________________________
Permalink | Reply | 4 comments |
headers
Brian Adamson | 14 Mar 2005 16:01
Picon
Picon

Re: reliable multicast transport via satellite

Marco,

The NORM (RFC3940/3941) approach has been successfully used in this 
scenario in a number of different systems.  The NORM provision to 
allow the receiver  group to "unicast" feedback to the sender and the 
sender facilitation of feedback suppression by multicasting control 
messages on the forward channel can work in a fairly scalable 
fashion.  I have worked with a deployed system where 10,000+ receiver 
ground stations have received reliable multicast transmissions from a 
satellite service while providing unicast feedback via terrestrial 
wired network connectivity.  The feedback requirements of NORM (given 
NACK-oriented operation) is quite small and well-suited for 
asymmetric connectivity with limited feedback capacity.

We have a working, open source, implementation of NORM, including 
support for building an "ns-2" simulation model at: 
<http://norm.pf.itd.nrl.navy.mil>.  I have also recently posted a 
"Developer's Guide" which described the NORM API available for 
application development using our NORM protocol implementation.

best regards,

Brian Adamson

At 12:16 PM +0100 3/14/05, Marco Tana wrote:
>Dear all,
>could you kindly report about IETF/RMT-WG point of view about 
>reliable multicast transport via satellite?
>I am working on this topic, I found many protocols in literature but 
>no IETF RFC/drafts at all! I noticed that MFTP proposal has
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Luby | 14 Mar 2005 22:10
Favicon

RE: reliable multicast transport via satellite

Marco,
In addition to the NORM approach that Brian outlines below, the FLUTE/ALC
(RFCs 3926, 3450, 3451, 3452, etc.) approach is the other one you should
consider.  The FLUTE/ALC approach relies fundamentally on powerful FEC codes
for the reliability, and is particularly well-suited for the situation you
describe for delivering bulk data reliably, and can do this without relying
fundamentally on feedback for reliability.  Note that the FLUTE/ALC approach
is now being proliferated into commercial standards: it has already been
adopted within 3GPP for the MBMS (Multimedia Broadcast/Multicast Service)
file delivery service, and is being considered by a number of other
standards such as DVB-H.  Note also that the FLUTE/ALC protocol is currently
being used in the commercial world for applications of the type you outline
in your email (please contact me privately for more information on this).
Regards, Michael Luby

-----Original Message-----
From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On Behalf Of Brian
Adamson
Sent: Monday, March 14, 2005 7:01 AM
To: Marco Tana; rmt <at> ietf.org
Subject: Re: [Rmt] reliable multicast transport via satellite

Marco,

The NORM (RFC3940/3941) approach has been successfully used in this 
scenario in a number of different systems.  The NORM provision to 
allow the receiver  group to "unicast" feedback to the sender and the 
sender facilitation of feedback suppression by multicasting control 
messages on the forward channel can work in a fairly scalable 
fashion.  I have worked with a deployed system where 10,000+ receiver
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent Roca | 16 Mar 2005 11:27
Picon

Re: reliable multicast transport via satellite

Dear Marco and RMT'ers,

Michael Luby wrote:
> Note that the FLUTE/ALC approach
> is now being proliferated into commercial standards: it has already been
> adopted within 3GPP for the MBMS (Multimedia Broadcast/Multicast Service)
> file delivery service, and is being considered by a number of other
> standards such as DVB-H.

I take advantage of this mail to inform those of you who may be
interested by this topic that Rod, Toni and Harsh did an excellent
tutorial on the subject, entitled "Advances in mass media delivery
to mobiles", during the MIPS 2004 workshop we organized last year.
Furthermore they kindly authorized us to put the slides in the web
site (once again, thanks a lot for that).

http://mips2004.inrialpes.fr/tutorials.php
http://mips2004.inrialpes.fr/files/MIPS2004-MMM_tutorial.pdf

> Note also that the FLUTE/ALC protocol is currently
> being used in the commercial world for applications of the type you outline
> in your email (please contact me privately for more information on this).

And keep in mind there are three open source FLUTE implementations
in addition to DF and Nokia's one.

Regards,

   Vincent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Eubanks | 16 Mar 2005 12:52

Re: reliable multicast transport via satellite

On Mon, 14 Mar 2005 12:16:21 +0100
 Marco Tana <marco.tana <at> unile.it> wrote:
> Dear all,
> could you kindly report about IETF/RMT-WG point of view about reliable 
> multicast transport via satellite?
> I am working on this topic, I found many protocols in literature but no 
> IETF RFC/drafts at all! I noticed that MFTP proposal has expired...
> Which is the right direction to investigate? Particularly wrt reliable 
> bulk data transfer with wired feedback channels?
> Sincerely grateful
> -Marco

Focusing on transport more than reliable, if you are planning to do true IP
multicast over a very assymetrical path, you should be aware of UDLR and RFC3077.
There are a number of issues that satellite transmission links impose that this
solves.

http://www.ietf.org/rfc/rfc3077.txt
http://www.udcast.com/udlr/

Regards
Marshall Eubanks

> -- 
> "Be liberal in what you accept, and conservative in what you send."
> Jon Postel - Internet Pioneer
> ___________________________________________________________________
> 
> Marco Tana
> Center for Advanced Computational Technologies
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod.Walsh | 17 Mar 2005 16:08
Picon

RE: reliable multicast transport via satellite

Hi All

The choice depends on 2 things:
 - your requirements
 - how much work you want to put in

The size of population, the level of reliability (and time to achieve sucessful delivery), the size of data
fragments, the relative cost and availability of up and downlinks - all these have an effect. What kinds of
use cases and users do you want to support?

I would recommend these sites for a coder's investigation into FLUTE:
http://atm.tut.fi/mad/
http://www.inrialpes.fr/planete/people/roca/mcl/mcl.html

Maybe someone can offer the same for NORM and UDLR.

Cheers, Rod.

> -----Original Message-----
> From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org]On 
> Behalf Of ext
> Marshall Eubanks
> Sent: Wednesday, March 16, 2005 1:52 PM
> To: Marco Tana; rmt <at> ietf.org
> Subject: Re: [Rmt] reliable multicast transport via satellite
> 
> 
> On Mon, 14 Mar 2005 12:16:21 +0100
>  Marco Tana <marco.tana <at> unile.it> wrote:
> > Dear all,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane