[Rmt] Suggested wording changes to FLUTE

["Luby, Michael" <[e-mail]>]

Vincent, RMT,
I suggest replacing the second to last paragraph of Section 3.3 to the attached.  (There were some grammar errors, and some ambiguities, that I think the replacement text cleans up.)  Also, my affiliation at the end was changed to Qualcomm, but the affiliation on the top right header of the first page still reads Digital Fountain and this should also be changed.
Regards, Mike


On 12/23/09 12:00 PM, "[e-mail]" <[e-mail]> wrote:

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/rmt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send Rmt mailing list submissions to
        [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rmt
or, via email, send a message with subject or body 'help' to
        [e-mail]

You can reach the person managing the list at
        [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rmt digest..."


Today's Topics:

   1. I-D Action:draft-ietf-rmt-flute-revised-08.txt
      ([e-mail])
   2. Updated version of FLUTE-revised (Vincent Roca)
   3. revised FCAST I-D (Vincent Roca)


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

Message: 1
Date: Wed, 23 Dec 2009 10:00:02 -0800 (PST)
From: [e-mail]
Subject: [Rmt] I-D Action:draft-ietf-rmt-flute-revised-08.txt
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"



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

Message: 2
Date: Wed, 23 Dec 2009 19:10:34 +0100
From: Vincent Roca <[e-mail]>
Subject: [Rmt] Updated version of FLUTE-revised
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Magnus, Mike and everybody,

I've just submitted version -08 of FLUTE revised:

http://tools.ietf.org/html/draft-ietf-rmt-flute-revised

Please find below answers to the comments you sent to the list on
September 1st
WRT version -06. I removed the comments already addressed by Toni in
version -07.
I have also attached comments already sent on the list beginning of
December with
Mike answer to this email. Comments are of course welcome.

Regards,

Vincent

 > >> >> 4. Section 1. As the ALC PI isn't suitable for general
 > >> >> deployment using unicast, flute can't really either. The
 > >> >> congestion control is the issue.
 > >> >>
 > > >
 > > > [Toni] Reviewing section 1 and sub sections of section 1 I think
this item is stated.
 > > >
 > > > Especially:
 > > > "FLUTE can be used with both multicast and unicast delivery, but it's
 > > > primary application is for unidirectional multicast file delivery.
 > > > FLUTE requires connectivity between a sender and receivers but does
 > > > not require connectivity from receivers to a sender. FLUTE
 > > > inherently works with all types of networks, including LANs, WANs,
 > > > Intranets, the Internet, asymmetric networks, wireless networks, and
 > > > satellite networks.
 > > >
 > > > FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
 > > > is IP version specific. FLUTE works with both multicast models: Any-
 > > > Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
 > > > [16].
 > > >
 > > > FLUTE is applicable for both Internet use, with a suitable congestion
 > > > control building block, and provisioned/controlled systems, such as
 > > > delivery over wireless broadcast radio systems."
 > > >
 > > > Do you think I should change section 1 somehow? If so, how?
 >
 > In some sense the information are there, but it is not made particularly
 > clear that unicast delivery over Internet is lacking a good congestion
 > control mechanism to my knowledge. Currently the only thing that I can
 > think of is using Webrc or at least reception monitoring and then a
 > separate control protocol to stop the streams.
 >
 > In general the massive scaling properties are colliding with unicast.
 >
 > Thus could we make this clear in Section 1.1.4?

[VR] I've added a paragraph in section 1.1.4, as suggested. New text:
"FLUTE can also be used for point-to-point (unicast) communications.
At a minimum, implementions of ALC MUST support the WEBRC [27]
multiple rate congestion control scheme [2]. However, since WEBRC
has been designed for massively scalable multicast flows, it is not
clear how appropriate it is to the particular case of unicast flows.
Using a separate point-to-point congestion control scheme is another
alternative. How to do do that is outside the scope of the present
document."


 > >> >> 5. Section 3.3, there is a reference to the NTP time format.
 > >> >> NTP v4 has been to IESG but are not approved yet. Are there a
 > >> >> point of actually referencing the clarified formats in that
 > >> >> doc? That also have a clarified discussion about epochs that
 > >> >> helps handling the wrap around.
 > >> >>
 > > >
 > > > [Toni] How would you change the current statement "Handling of
wraparound of the 32 bit time i
s outside the scope of NTP and FLUTE."
 > > > I cannot come up with any other more accurate statement for this
part of the spec.
 >
 > Well, the new NTP spec does discuss epochs. And if you have a local
 > clock, then you can actually know which epoch it currently are and apply
 > that. That seems the most reasonable handling of this wrap around.
 >
 > Maybe an informal pointer about the handling of epoch to
 > draft-ietf-ntp-ntpv4-proto. Section 6 seems to be the main
interesting one.

[VR] Good point (I was not aware of the era/epoch concept of NTPv4). New
text:
"These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900 in case of the prime epoch (era 0) [20]. The handling of
time wraparound (to happen in 2036) requires to consider the
associated epoch. In any case, both a sender and a receiver can
easily determine to which (136 year) epoch the FDT Instance
expiration time value pertains to."
However, with this new sentence, I have the feeling NTPv4 needs to be
in the Normative References section, i.e. we create a dependancy with
NTPv4 (for the moment only NTPv3 is normative, NTPv4 is informative)...


 > >> >> 7. Section 3.4.2:
 > >> >>
 > >> >> Why is only HTTP URLs valid in the location header? In
 > >> >> addition why was HTTP URLs used? There is after all an
 > >> >> explicit transport mechanism implied by that. Some
 > >> >> clarification on that relation would be good.
 > >> >>
 > > >
 > > > [Toni] At the time of design it was found that "Content-Location"
serves the purpose best. I s
ee no problem allowing any generic URL. Would you be so kind and provide
me normative reference for
generic URL? Would http://www.rfc-editor.org/rfc/std/std66.txt do?
 > > >
 >
 > Actually by referencing HTTP (RFC 2616) you actually get that generic
 > URI are allowed in the header. So from a syntax perspective this appears
 > to be fine. So actually I might have misinterpreted the spec myself here.
 >
 > I still find the relation between the URI space used in the
 > Content-Location header and FLUTE a bit unclear. I wished this was clear
 > explained, but I will not demand that you improve this.

[VR] I havn't done anything. Please tell me if I should.


 > >> >> 10. Section 6:
 > >> >>
 > >> >> Shouldn't this text discuss the need for configuring the
 > >> >> congestion control mechanism also? The security parameters
 > >> >> needs discussion also.
 > >> >>
 > > >
 > > > [Toni] The congestion control parameters to be used depend on the
congestion control block to
be used. Same goes for security. I suggest adding two bullets in the
list of non-exhaustive list of
optional items:
 > > > * Definition and configuration of congestion control mechanism
for the session
 > > > * Security parameters relevant for the session
 > > >
 > > > Is this OK?
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.


 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?


 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.


 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.


 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?


 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.


 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > Good, please add the chairs and me into the loop.

[VR] Based on this discussion and the comments you and Mark sent on
Sept 3rd, I remove any reference to URN in this section.


[VR] Finally, I moved Rami Lehtonen to the end of the author list since he
did not contribute (at least significantly) to this revised version AFAIK.
I've also updated Mike's address.


[VR] Concerning the security aspects, I've modified section 7 and added
section 7.5. "Minimum Security Recommendations", (in line with ALC
recommendations). I also moved from SHA-1 to SHA-256 to be in line
with IETF general recommendations.


 >>>>>>> 6. Section 3.4.1:
 >>>>>>> Mandatory receiver behavior for handling FDT Instance
 >>>>>>> ID wraparound and other special situations (for example,
missing FDT
 >>>>>>> Instance IDs resulting in larger increments than one) is
outside the
 >>>>>>> scope of this specification and left to individual
 >>>>>>> implementations of
 >>>>>>> FLUTE.
 >>>>>>>
 >>>>>>> Why isn't this specified. Seem to be important for
interoperable usage.
 >>>>>>> Seems to be a fine thing to gloss over in an experimental, but
 >>>>>>> not in a proposed standard.
 >>>>>>>
 >>>>> [Toni] The text states that what actions the special situation
causes in the receiver is up to
receiver. In a same way your web browser will typically show a different
error message than my tryi
ng to access http://ww.w3.org. I see one valid
 >> implementation trying to recover from situation by staying longer in
the session and trying to de
duce what happened. Meanwhile I see another implementation possibly
using out of band methods (if av
ailable) for the same. In other words, error recovery or
 >> concealment or similar is not in the scope of the spec.
 >>> Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
 >>> clearly not impossible. As it from my perspective looks like where
error
 >>> conditions could be avoided by specifying the correct behavior.
 >>
 >> [VR] I agree with Toni W.R.T. the problem of FDT Instance ID wraparound
 >> when the two FDT Instances are non expired. It's clearly an erroneous
 >> situation and how to address it is out-of-scope.
 >>
 >> There's just an (easy to fix) issue in sections 3.1 and 3.3 that say:
 >> "Each File Delivery Table Instance is uniquely
 >> identified by an FDT Instance ID."
 >> which contradicts the possibility of wraparound. I think that saying:
 >> "Each non-expired..."
 >> solves it.
 >>
 >>
 >> Now I don't agree with Toni W.R.T. the case of missing FDT Instance ID
 >> (or IDs). IMHO this is not a special situation but a *common situation*.
 >> That's typically what terminals with intermittent connections
experience.
 >> I suggest to make the support of this situation MANDATORY.
 >>
 >> There are implications here, since FDT Instance management is rather
 >> flexible, see Section 3.2:
 >> "Any FDT Instance can be equal to, a subset of, a
 >> superset of, or complement any other FDT Instance. A certain FDT
 >> Instance may be repeated several times during a session, even after
 >> subsequent FDT Instances (with higher FDT Instance ID numbers) have
 >> been transmitted."
 >> So if FDT Instances complement one another rather, there could be
problems.
 >> More precisely, imagine FDT Instance 1 describes objects A and B. Then
 >> object C is added. If the sender chooses to describe only object C in
 >> FDT Instance 2 (i.e. FDT Instances 1 and 2 complement each other) and
 >> not to transmit FDT Instance 1 any more (it's authorized), a
receiver that
 >> missed FDT Instance 1 will not be able to process objects A and B, even
 >> if he received enough encoding symbols for them.
 >> Admitedly, it does not break the receiver, so it's safe, but it remains
 >> largely sub-optimal.
 >>
 >> So, IMHO, we should also clarify that a FLUTE sender SHOULD NOT assume
 >> receivers will receive all FDT Instances, i.e. it is RECOMMENDED that
 >> FDT Instances be managed in such a way to make the FLUTE session robust
 >> in front of FDT Instance losses. One possibility is to use only
 >> self-sufficient FDT Instances, another one is to repeat all FDT
Instances
 >> that complement each other at a given moment.
 >>
 >> Having said that, I don't know if such a recommendation is in line with
 >> current FLUTE deployment guidelines (e.g. in DVB-IPDC) ? Any comment or
 >> additional piece of information here?
 >
 >Vincent, I think your recommendations are good. However, also I am
 >lacking information about thus. However, I don't see that a
 >recommendation will create any serious issue for our users. They can
 >either accept it or explain why their usage should ignore the
 >recommendation.
 >
 >*** (MGL) To clarify, what I suggest is to say that ?... a FLUTE
sender SHOULD assume receivers will
 > not receive all packets pertaining to FDT instances, i.e., it is
RECOMMENDED that FDT instances be
 > managed in such a way that a receiver will be able to recover at
least one FDT instance describing
 > a file delivered within the FLUTE session with as much or greater
reliability as the receiver is able
 > to receive enough packets containing encoding symbols for the file to
recover the file. As an example,
 > one way to satisfy this recommendation is to repeat FDT instances
describing the file often enough. As
 > another example, another way to satisfy this recommendation is to use
an FEC code for an FDT instance
 > describing the file and send encoding symbols for the FDT instance
often enough.? BTW, I
 > didn?t understand what it meant to be ?self-sufficient?, nor what it
meant to ?repeat all FDT instances
 > that complement each other at a given moment?. I?m guessing that
?self-sufficient? means an FDT
 > instance that describes all files being delivered at that time? And,
?repeat all FDT instances th
 > at complement each other at a given moment? means something like
repeat all FDT instances that are
 > relevant to a particular receiver at a given moment? (But I?m not
sure if complement is used here in
 > the same sense as how complement is used elsewhere in the draft, and
it seems like it is different
 > as the other sense of complement doesn?t make sense here.) Anyway,
perhaps these examples could be
 > fleshed out a bit?

[VR] Thanks Mike for the text proposal. It is indeed what I had in mind
(but did
not express sufficiently well). What I did is the following:

1/ I've modified section 3.3 where the issue of sending FDT reliably was
already
discussed. I now distinguish two complementary aspects: (1) the reliable
transmission of an FDT Instance (through repetition and/or FEC encoding),
and (2) the way the FDT is delivered as FDT Instances which also impacts
reliability.

2/ I've modified section 3.4.1 to correct what should be considered as
erroneous
situations. I've also corrected an incoherency since it was said that:
"A new FDT Instance reusing a previous FDT Instance ID number, due to
wraparound, may not implicitly expire the previous FDT Instance with
the same ID."
(note the use of "may") whereas it was previously said that after wraparound
only expired FDT Instances can be considered while choosing an FDT
Instance ID.
Please see the -08 version or the diff for the details. The
modifications I've
done are not insignificant. For instance, FDT Instance ID wraparound
handling
MUST be supported.



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

Message: 3
Date: Wed, 23 Dec 2009 19:15:18 +0100
From: Vincent Roca <[e-mail]>
Subject: [Rmt] revised FCAST I-D
To: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Everybody,

I've also submitted a revised FCAST I-D, as a WG Item document
(it still needs to be approved as a -00 document, so it's not yet publicly
available).

The main differences WRT previous version concern the security
section. I've updated this section to add a "Minimum Security
Recommendations" similar to that of FLUTE, and in line with both
ALC and NORM recommendations.
It's now ready for an official WGLC.

Cheers,

    Vincent


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

_______________________________________________
Rmt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rmt


End of Rmt Digest, Vol 65, Issue 5
**********************************