Subject: [Rmt] Responses to the FLUTE discussion in RMT WG meeting in Minneapolis

From: [email-masked]
Date: Thu, 13 Nov 2003 13:41:51 +0200

Hi All,

Thanks to everyone involved in the FLUTE discussion in the RMT working
group.  This email is meant to detail and address all of the concerns raised
in the RMT wg meeting. 

Right after this email, I will send the revised -05 version of the FLUTE
draft based on addressing all of these concerns.  It would be great to have
working group last call on the draft immediately to move it to an
Experimental RFC. 

The issues raised fall into these areas:

(1) Congestion control and layering: are we confident that FLUTE can handle
multiple layers and congestion control without any additional implications
specific to FLUTE?

(2) Interoperability tests did not test multiple layers of congestion
control -- is this a place where FLUTE might have issues beyond those of
ALC?

(3) Security concerns: Have we analyzed the additional security
consideration that FLUTE introduces above ALC: FDT attacks?

(4) Does FLUTE address all of the issues outlined in the Building Block and
Protocol Instantiation Design RFC?

(5) Is there any time urgency for pushing FLUTE to Experimental RFC?

Lastly, I would like to thank all of you who participated resolving the 
set of issues raised, an especially acknowledge the hard work and 
contributions from Mike and Rod.

Regards,
  Toni

----------------------------------------------------------------------------

Responses to the above concerns are below

(1) Congestion control and layering: are we confident that FLUTE can handle
multiple layers and congestion control without any additional implications
specific to FLUTE?

Yes, since FLUTE is built on ALC and ALC handles multilayering, by
inheritance FLUTE does as well.  The only place where multilayering might be
different in FLUTE is that it makes a distinction between two types of data
delivered to receivers: FTDs and files. The reason this distinction is
important in FLUTE is because the receiver needs to receive FTDs in order to
understand how to receive files, and thus in this sense FTDs are of higher
importance to receive than files.  Text has been added at the end of Section
3.3 of the attached FLUTE draft to explain this issue, and it is recommended
to send FDT Instances frequently enough so that the file description can be 
recovered at least as reliably as the file it describes, and it also recommends 
the use of non-trivial FEC codes for FTD Instance delivery if the FTD Instance is
generally longer than one encoding symbol in length so that receivers will be able to
recover the FTD Instances at least as reliably as the files they describe.

(2) Interoperability tests did not test multiple layers of congestion
control -- is this a place where FLUTE might have issues beyond those of
ALC?

With regards to the interoperability tests done so far with FLUTE, these
interoperability tests were primarily targeted at testing the FLUTE
functionality added onto ALC and not the basic ALC functionality.  There has
been a lot of experience with ALC deployment by Mike (Digital Fountain), using
multilayering and congestion control (WEBRC) in commercial environments, and
these deployments have been quite successful and have led to feedback that
informed the WEBRC building block but did not affect ALC (or FLUTE).  The
only place where multilayering might have an impact specific to FLUTE is
again with respect to delivery of FDT Intances.  Text has been added to the
end of Section 4 to discuss this issue and provide recommendations. In
summary, the FDT Instance packets should not be concentrated on the higher
layers because lower rate receivers won't receive them, and a non-trivial
FEC Encoding ID should be used to deliver FDT Instance packets if FDTs are
generally longer than one encoding symbol in length and if FDT Instance
packets are sent to more than just the bottom layer.

(3) Security concerns: Have we analyzed the additional security
consideration that FLUTE introduces above ALC: FDT attacks?

The security section in the attached revised FLUTE draft has been rewritten
into the style of the ALC security section (which has already been approved
as an Experimental RFC).  Furthermore, the additional FLUTE vulnerabilities
of forging FDT Instance packets and the possible consequences of this
has been called out and countermeasures for how to prevent such attacks has 
been recommended.  It is not a good idea to require any of these security 
measures, because which ones are applicable depend on the deployment 
environment of the application (from a closed system with security measures 
already in place to a completely vulnerable open Internet deployment), and 
much of the security work is still ongoing for multicast in the MSEC working 
group.  Thus, FLUTE follows the same style as ALC.

(4) Does FLUTE address all of the issues outlined in the Building Block and
Protocol Instantiation Design RFC?

Although FLUTE is not literally a protocol instantiation (it is more like an
application that uses a protocol instantiation), it was noted that FLUTE -04
did not describe the application space for FLUTE.  Thus, Sections 1.1 has
been added in the attached revision of FLUTE to provide an Applicability
statement.

(5) Is there any time urgency for pushing FLUTE to Experimental RFC?

Other standard bodies such as 3GPP and DVB are making decisions now and are
looking to the IETF for available, or soon to be available specifications 
for a unidirection file delivery standard, and if FLUTE is not made into 
an Experimental RFC almost immediately these other standards bodies will 
settle on in some cases much less technically appropriate (not designed for 
file delivery) but already standardized solutions and in other cases on 
ad hoc solutions very weak technically.  

It should be noted that in no case would widespread deployment happen 
immediately -- there would be a long period of experimentation before 
widespread deployment -- and during this experimental period 
(of perhaps two-three years) more experience would be gained with the 
FLUTE Experimental RFC and it would become a Proposed Standard before 
widespread deployment.  The same statement of intent to move this to a 
Proposed Standard as appears in ALC (and has been agreed upon for all 
RFCs in the RMT wg) has been added to the end of the introduction to 
state this intent.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt