Subject: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-signaling

From: Marshall Eubanks <[email-masked]>
Date: Sat, 18 Apr 2009 14:04:14 -0400

I think that this document is also ready, so I would like to issue
a working group last call on draft-ietf-fecframe-config-signaling-01.  
This document can be
found at

http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling-01.txt

I encourage everyone to read this document and comment during the last  
call period.

This last call will end on Monday, May 4th, 2009.

Regards
Marshall Eubanks

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Apr 2009 18:22:50 -0700

These are my comments for this draft. I suppose due to normative references, this document will have to wait for the framework and SDP drafts anyway.

BR,
-acbegen

- Page 4:

   "This document does not make any assumption that the 'FEC sender and 
   receiver' functionality and the 'Media Source/Receiver' functionality 
   are implemented on the single device, though it may be the case."

Should read:

"This document does not make any assumption that the Media Sender and FEC Sender functionalities or the Media Receiver and FEC Receiver functionalities are implemented on the same host, although this may be the case."

- page 5:

   "Each instance of the FEC Framework muse use a single encoding format 
   to describe e.g. encode all of the configuration information 
   associated with that instance."

I believe we need to make it clear that an FEC scheme can support multiple signaling protocols but it must use a single encoding format in a particular instance.

- page 5 and beyond:

"Unicasted", "multicasted" should be "unicast", "multicast".

- page 10:

There is an editor's note, which should be removed (the note itself could be kept). 

- Section 4.2.2:

Is this section suggesting/assigning/registering any new RTSP parameters? If so, is there a proper way of doing it? Any IANA considerations that this document needs to have?

- Section 4.2.3:

Not sure how useful this section is. At least, the document should provide the references for the mentioned specs.

Nits:
- "Configuration Information" is sometimes capitalized, sometimes not. The document needs to be consistent. 
- Typo in page 2: "FEC scheme specifics information". Use FSSI where possible.
- Need for plural versions at the end of Section 1, i.e., multicast applications, unicast applications, security considerations. "section X" should be "Section X".
- Inconsistent capitalization in the numbered list on page 3.
- Missing commas before and after "i.e."
- Spell out "OAM" on page 4
- "provide a mean" --> "provide a means" on page 4
- The capitalization of special words like "MUST, MAY, SHOULD" be checked as there are many occasions where the capitalized versions would probably make more sense. 
- Typo on page 9: "doesn't already exists"
- Conclusions section can be removed.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marshall Eubanks
> Sent: Saturday, April 18, 2009 11:04 AM
> To: [email-masked]
> Subject: [Fecframe] Working Group Last Call 
> ondraft-ietf-fecframe-config-signaling
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: Vincent Roca <[email-masked]>
Date: Wed, 29 Apr 2009 11:25:52 +0200

Hello,

Here is my review of the fecframe-config-signaling I-D.
I didn't look at Ali's comments, so this is a totally
independent review.

Regards,

  Vincent

Comments to draft-ietf-fecframe-config-signaling-01.txt
Vincent - April 29th, 2009
-------------------------------------------------------

For discussion...

I- Main comments
----------------

1/ Sections 4.1.1 and 4.1.2: administrative scoping with multiple FecFrame sessions
-----------------------------------------------------------------------------------

In case IPv4 administrative scope is selected, the target multicast
address must be set to 239.16.33.254 (section 4.1.1 and 4.1.2).
What happens if two senders in the same LAN need different non overlapping
administrative scoping regions? As I understand, scoping is configured per
address, and since there's a single address, the associated scoping region
must be in that example the union of the two disjoint scoping regions.
Not very effective...

Additionally, why this magic value of 239.16.33.254? Is there any good
reason for choosing this value and not a different one? If the choice
is arbitrary, it should be mentioned. Same remark for 239.16.33.254.

2/ Sections 4.1.1 "Sender procedure": stopping the FEC Framework Instance
-------------------------------------------------------------------------

It is said:
   The sender must periodically send the 'SAP announcement' message.
   This is required so that the receiver doesn't purge the cached
   entry(s) from the database and doesn't trigger the deletion of FEC
   Framework configuration information.

I don't understand why a receiver who correctly obtained the FEC
Framework Config Info should stop its FEC Framework Instance, just
because he doesn't receive any SAP announcement for this instance
any more. What matters most is the fact the receiver still receives
the source/repair packets for this instance.
I suggest to keep the two aspects separate rather than creating implicit
relationships between them.

3/ Sections 4.1.1 "Sender procedure": 'time interval'
-----------------------------------------------------

It is said:
   Additionally, the 'time interval' should be signaled within the FEC
   Framework configuration Information.

There is no such requirement in the FEC Framework I-D. This "time interval"
is specific to the use of SAP and has nothing to do with the FEC Framework.

More generally, if SAP defines a "very sophisticated but complex formula"
(as said in the I-D) to define the time interval, there are probably good
reasons. I'm not convinced by the explanation provided to justify the use
of a fixed value, especially when the conclusion consists in saying that:
"The SAP implementation should provide the flexibility to the operator to
choose the complex method over the simpler method..."

What should be done? We need guidelines here.

4/ Section 4.1: On the use of SAP
---------------------------------

More generally, the use of SAP as the technical transport mechanism for multicast
session descriptions should be discussed. It's available, standardized, simple,
which is good. But there are also major limitations that should not be ignored.
FYI, with Hitoshi, we tried to clarify them in the following I-D:

http://tools.ietf.org/id/draft-ietf-mboned-session-announcement-req-01.txt

I'm not saying that SAP should not be used, but its limitations should be
mentioned.

5/ Section 4.1.2 "Receiver Procedure": max timer value
-------------------------------------------------------

It is said:
   ...the timer of the corresponding entry should be reset to the three times
   the time-interval value that is signaled by the sender or one hour,
   whichever is greater.

The consequence is that an entry is kept at least 1 hour. I don't understand
the motivation, especially if we consider that the default "time interval"
is 60 seconds (previous section), which means that "three times the time-interval
value" defaults to 3 minutes... There is a huge gap!

6/ Section 5. "Security considerations"
---------------------------------------

Are you really sure that:
  "There is no additional security consideration other than what's 
   already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP 
   etc. "
And please, remove the final "etc." ;-)

II- Sentences to clarify
------------------------

** p2, Introduction:
It is said:
  "This document describes how
   to use various signaling protocols to determine and communicate the
   Configuration information between sender and receiver(s)."
I don't understand "determine". Do you mean "provide a way for the receiver(s)
to determine the FEC Framework Conf Info? This sentence seems ambiguous to me.

** p3: the following paragraph:
  "Content Delivery Protocol (CDP) is defined as a complete (suite of)...
   [...] as defined in the FEC Framework document [FECARCH]."
can probably be improved.

** p3 and p4, Terminology/Abbreviations: 
I suggest to append "(s)" to the "flow", to the "FEC stream" and to the
"media receiver" since there can be several of them. 

** p5, section 3.1 "Encoding format".
It is said:
  "Whatever encoding format is selected for a particular FEC framework
   instance, it must be known by the signaling protocol. "
I don't like "it must be known by..." which could be interpreted as
"the signaling protocol must be able to analyze the encoding format"
which is probably not the intent.
I suggest:
  "The FEC Framework instance MUST communicate the encoding format used
   to the signaling protocol."

** p6, section 4.
It is said:
  "It is important to note that there may be either only one receiver
   needing the FEC Framework configuration information to FEC protect a
   "unicasted multimedia stream"..."

I don't like the whole sentence. I suggest:
   Sometimes, the multimedia stream is unicast to a single receiver (e.g., with
   Video On Demand) and the FEC Framework Configuration Information MUST be
   communicated only this receiver. In other situations, the multimedia stream
   is multicast to several receivers (e.g., with Broadcast TV or IPTV) and the
   FEC Framework Configuration Information MUST be communicated to all of them.

** p8:
Rather than saying: "...MAY be subjected to the cryptography." I suggest
"...MAY be encrypted."

Later on, after the Figure, it is said:
  "While the RFC2974 includes explanation for each field, it is worth
   discussing the 'Payload' and 'Payload Type' field. This field must be..."
Two comments:
 - "fields." and not "field." in the first sentence.
 - "The 'Payload' field must be used... in the second sentence.

** p 9, section 4.1.1. "Sender Procedure"
It is said:
  "This is the preferred method, though the
   other method may be to aggregate more than one SAP (announcement)
   messages in a single UDP datagram as long as the resulting UDP
   datagram length is less than the IP MTU of the outgoing interface."

I suggest:
 - to split it into two sentences. "This is the preferred method. Another..."
 - to clarify that in the second method, there is one SAP announcement
   message per FEC Framework instance.
 - And finally, a third solution could be to send the SAP announcement
   messages separately... It's still possible and could make sense if each
   instance is managed separately, in a different OS process. It should
   also be mentioned.

** p9, section 4.1.1: IPv6 compatibility
Signaling protocols can work on both IPv4 and IPv6. However, the text should
not be restricted to IPv4 field names, as is the case in section 4.1.1:
   "The default IP TTL value should be 255, ..."
TTL in IPv4 => "Hop Limit" in IPv6

** p10, section 4.1.1:
It is said:
  "The sender may choose to delete the announced FEC framework 
   configuration information by sending a 'SAP deletion' message. This  
   may be used if the sender no longer desires to send any FEC streams."

I have the feeling that "no longer desires to send any FEC streams" is
too strong. He can just want to close a stream, no matter whether he will
define and send new streams in the future.
In any case the comment I-2/ above applies here.

** p 11, section 4.2:
I suggest to simplify...
"the node acting as the offerer" => "the sender"
"the node acting as the answerer" => "the receiver"
if I understood correctly.

** p13, section 4.2.2:
It is said:
  "The requesting node (Node1) may then send either the SETUP message
   without using the Require: header, if the remote node didn't support
   the "FEC protection", or a new SETUP message to request the selected
   FEC protection streams."

This paragraph follows the exchange depicted in the figure, if I
understand correctly.
So the use of FEC Protection is already accepted and there is no reason
to mention the case where FEC protection is not supported.
I think the paragraph needs to be reorganized so that the two situations
(200 versus 551) are considered.
Additionally, I suggest that in the 200 OK response, the example mentions
several FEC Framework instances, so that the need of the second SETUP
message be more obvious.

III- Additional comments
------------------------

** p2, "Conventions used in this document"
Why is this section here, before the Table of Contents?
BTW, "C:" and "B:" are specified, however this is never used in the document!
Remove it.

** Whole document:
The use of upper case letters in "FEC Framework Configuration Information"
is not consistent in the document. Please make sure that this specified
term is always capitalized.

** Whole document:
I see several occurrences where "must" is not written in lower case whereas
it should be understood as "MUST". There is also a "must NOT" in section
4.1.1. Same remark for "should".

** Whole document:
Using of "etc." is a very bad practice. In an enumeration, you must either
provide the exhaustive list or say "for instance, ..." and provide a few
examples.

** Whole document:
On several occasions it is written: "the FEC Framework instance i.e. FEC scheme, ..."
(also "Scheme") => three times on p5, then once on p11.

I don't agree, a FEC Framework Instance is much more than simply a FEC scheme.
There are many framing/blocking/configuration/recovery mechanisms in addition
to the FEC codec.
I suggest to remove "i.e. FEC scheme".

** Fig. 1:
What is the added value of "MPLS network"? I suggest to remove it.

IV- Typos
---------

** p3: "how are source blocks are constructed" -> "how source blocks are constructed"

** p3: remove "<What is CDP>"

** p3: remove:
"  Copyright (C) The IETF Trust (2008).  This version of this MIB module
   is part of RFC XXXX; see the RFC itself for full legal notices."

** p6:
Missing " " (space) in the following sentence: "sender),the receiver(s)"

** p6: 
Remove "describing using" in sentence:
"Such diversity necessitates describing using at least two types of..."

** whole document:
"multicasted" and "unicasted" do not exist => "unicast" and "multicast"

** p7: remove the final "s" to "obtains" in:
"   enables the receiver to receive the SAP message(s) and obtains the"

** p12: "SIP already uses offer/answer model" => "SIP already uses an offer/answer model"

** remove "section 7. Conclusions"