Subject: [AVT] WGLC comments on draft-ietf-avt-avpf-ccm-03.

From: "Even, Roni" <[email-masked]>
Date: Mon, 11 Dec 2006 15:36:11 +0200

Hi,
Some initial comments and nits.

1. In the abstract section suggest adding "ITU-T" before "H.271 video back channel"

2. In section 1 fifth paragraph "The Temporary Maximum Media Bandwidth Request (TMMBR) Message allows to signal, from media receiver to media sender, the current maximum supported media bit-rate for a given media stream" suggest changing supported to requested

3. In section 1 typo "preferred" should be "preferred"

4. In the definition in glossary for TSTA is "Temporal Spatial Trade-off Announcement" but according to the terminology it should be a notification. Suggest either changing the name or defining announcement as notification in the terminology section.

5. In the terminology section " To the best of the author's knowledge, the term "Decoder Refresh Point" has been formally defined only in H.264; hence   we are referring here to this video compression standard" 
I could not find this term I H.264 and it is not part of the ITU terminology database in SANCHO - http://www.itu.int/sancho/index.asp

6. In 3.1 item 3 "to the remote encoder a request of change" should be "to" instead of "of".

7. In the same section " and another use may prefer the opposite" should be user and not use

8. In 3.1 item 7 you mention AMID and TFRC but they are not defined and there is no reference.

9. In section 3.1 item 8 " It operates the receiver sending a feedback message to the sender" should be "it operates by the ..."

10. In section 3.2 " The topological locations of the signalling entities are also commonly not optimized for minimal delay, rather other architectural goals." Suggest "delay, but rather for ..."

11. In section 3.2 "Furthermore, AVPF implements rules controlling the timing of feedback messages  so to avoid congestion through network flooding. We re-use these rules by referencing to AVPF." 
suggest
"Furthermore, AVPF defines rules controlling the timing of feedback messages avoiding congestion through network flooding. We re-use these rules by referencing AVPF."

11. In section 3.5.1.1 second paragraph "timing rules the session operates under" suggest "timing rules applicable to the session"

12. In section 3.5.1.1 third paragraph "and MCU to decoder refresh point generating MCU". I think it should be "generating endpoint"

13. In section 3.5.2 "Index values from 0 to 31 indicate monotonically a desire for higher frame rate.". I am not sure what this sentence means. Is 1 higher frame rate than 0. Also what is the relation between frame rate and temporal and spatial resolution. Maybe have the text from 4.3.2.1

14. In section 3.5.2.3 "participants" instead of "participant's"

15. In section 3.5.2.4 third bullet, How does the sender know why his request was not accepted  so he will not send repetitive messages, maybe some text is needed saying that if in multicast or multipoint the sender SHOULD NOT expect that his request will be accepted and SHOULD NOT repeat it if acknowledged by a different value.

16. In section 3.5.3 I suggest adding "This memo addresses only the transport of those code-points." To the second paragraph and delete the next two paragraphs.

17. In section 3.5.3 5th paragraph change "currenty" to "currently"

18.In section 3.5.3 "4. When using the not multicast save messages" should be safe not save.

19. In section 3.5.4 4th paragraph "as negotiated during signalling." Suggest "as negotiated using call signalling."

20. In section 3.5.4.1 first paragraph delete "(A-D)"

21. In section 3.5.4.1 towards the end "and hence needs explicitly informed about desired bandwidth adjustments" suggest "needs to be explicitly ..."

22. Section 3.5.4.4 talks about reliability. I am not sure it is applicable to point o point calls or to an MCU case. It is more for multicast. If this it correct than it should say so.

23. In section 4.2.1.1 you have " TMMBR feedback SHOULD NOT be used if the underlying transport protocol is capable of providing similar feedback information from the receiver to the sender.". Do you mean that if using TCP you SHOULD NOT use TMMBR. TCP cannot address the multipoint case described.

24. in section 4.2.1.1 " If the value set by a TMMBR message is expected to be permanent the TMMBR setting party is RECOMMENDED to renegotiate the session parameters to reflect that using the setup signalling." Suggest call signaling and not setup

25. In section 4.2.1.2  " SSRC:   The SSRC value of the target of this specific maximum bit-rate request." Who is the target, is it the target for the media (the sender of the request) or the target for the request.

26. In section 4.2.2.1, I think that most of the text applies to multicast. Does all this apply to uni-cast?

27. In section 4.3.1.3 " onee" should be "one"

28. In section 4.3.4.2 " requiremnts" should be " requirements"

Thanks

Roni Even

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Dec 2006 20:39:40 -0500

Mostly nits, but one issue that could or is mis-understood (3.5.4).
(Roni may have hit some of these, especially spelling issues)

In 3.5.2, TSTA is used without a definition.  It is defined a lot earlier,
but if we're defining TSTR in 3.5.2, we should define TSTA in the same way
on first reference.

In 3.5.2.1, "the sender is not capable to adjust its trade-off" should be
"the sender is not capable of adjusting its trade-off".

In 3.5.4, it states that "the bit-rate negotiated in signalling is the one
that the participant guarantees to be able to handle (encode and decode)".
I'm not certain that's the case.  From RFC 3264 (Offer/Answer): "If the
bandwidth attribute is present for a stream, it indicates the desired
bandwidth that the offerer would like to receive" and "It SHOULD send media
using a bandwidth no higher than the value of the bandwidth attribute in
the offer, if any was present."

To me, that says (at least for offer/answer; the SDP RFC is less clear)
that bandwidth specs are for reception and say nothing about how fast an
endpoint will encode/send.

TMMBR appears to me to be "I don't want to receive faster than X", but says
nothing about how fast the they plan to send.  So the comments about encode
and "session maximum" appear to be at least confusing when combined with
Offer/Answer.  I don't see a problem with operation of TMMBR and the
Offer/Answer/b=, but I think we need to be clear than TMMBR sets a new
limit to reception, less than or equal to the rate the endpoint agreed to
receive at (NOTE: I explicitly didn't say "session bit-rate" or equivalent,
which implies a shared limit apparently not in Offer/Answer), but says
nothing about sending rates.

If nothing else, the above shows that the discussion of TMMBR needs
clarification. 

3.5.4 and also 4.2.1 and lots of other places: I find "sender of a media"
an awkward and potentially confusing wording.  We should use the same
terminology used in other RFCs: "sender of a media stream".  (See RFC 3264,
for example).

General question:  Are spellings supposed to be American English, British
English, mixed, or either but not both in the same document?

4.1, last paragraph:  "Media receivers are not always implementing" -> 
"Media receivers do not always implement"

It's probably not required, but do we need to worry about someone having
implemented the earlier drafts of RFC 4585 where Generic ACK was
assigned to FMT=2?

4.2.1.1: TMMBN is used without a definition.  It is defined a lot earlier,
but if we're defining TMMBR in 4.2.1, we should define TMMBN in the same way
on first reference.

4.2.1.1: "owner of the bandwidth limit" - this phrase is unclear to me.
4.2.1.1: "suppres" -> "suppress"
4.2.1.1: the paragraph beginning with "A media receiver..." is quite confusing.

Aha, later in 4.2.1.1 it defines owner of bandwidth limits - after using
it.  But it's still confusing, perhaps because it seems like TMMBR/TMMBN
amount to a shared limit, not a "I want to receive" limit.  (I.e. there's a
single limit per session, which doesn't jibe with Offer/Answer, which
implies each participant has an independent reception limit.)  Even with
the shared limit, I still find the "owner" concept confused.  Who starts
out being the owner?  I note that TMMBN starts with discussion of who an
owner is.

4.2.1.1: SSRC timeout - could this lead to multiple entities in a session
believing they're the owner?  Race conditions?  

4.3.1.1: For streaming, I'd suggest "skip forward" -> "skip forward or
backwards".  Minor.

4.3.1.3 "onee" -> "one"

4.3.2: TSTR - I realize this is a "relative" request, and it makes sense in
the case of the multiply-mentioned "slider".  However, in some cases a
receiver may have a real need (or a real request) for a maximum or specific
framerate.  For example, if display hardware is 25fps, the UA may wish to
tell the sender that sending faster is wasted, instead of having it try to
guess or hunt for what Index value will yield the desired framerate.  This
point of control is sometimes (often) not available at the signalling
level.  We should (re?)consider absolute requests (not requirements), both
for preferred rates and for maximums.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 12 Dec 2006 16:19:37 +0200

Hi,

For you general question, the spelling should be either but not mixed. 

As for 3.5.4 I agree that TMMBR sets a temporary new limit to reception,
less than or equal to the rate the endpoint agreed to receive at. It
needs clarification and using encode decode is not correct

Roni Even

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 3:40 AM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [AVT] WGLC comments on draft-ietf-avt-avpf-ccm-03.

In 3.5.2, TSTA is used without a definition.  It is defined a lot
earlier, but if we're defining TSTR in 3.5.2, we should define TSTA in
the same way on first reference.

In 3.5.2.1, "the sender is not capable to adjust its trade-off" should
be "the sender is not capable of adjusting its trade-off".

In 3.5.4, it states that "the bit-rate negotiated in signalling is the
one that the participant guarantees to be able to handle (encode and
decode)".
I'm not certain that's the case.  From RFC 3264 (Offer/Answer): "If the
bandwidth attribute is present for a stream, it indicates the desired
bandwidth that the offerer would like to receive" and "It SHOULD send
media using a bandwidth no higher than the value of the bandwidth
attribute in the offer, if any was present."

TMMBR appears to me to be "I don't want to receive faster than X", but
says nothing about how fast the they plan to send.  So the comments
about encode and "session maximum" appear to be at least confusing when
combined with Offer/Answer.  I don't see a problem with operation of
TMMBR and the Offer/Answer/b=, but I think we need to be clear than
TMMBR sets a new limit to reception, less than or equal to the rate the
endpoint agreed to receive at (NOTE: I explicitly didn't say "session
bit-rate" or equivalent, which implies a shared limit apparently not in
Offer/Answer), but says nothing about sending rates.

3.5.4 and also 4.2.1 and lots of other places: I find "sender of a
media"
an awkward and potentially confusing wording.  We should use the same
terminology used in other RFCs: "sender of a media stream".  (See RFC
3264, for example).

General question:  Are spellings supposed to be American English,
British English, mixed, or either but not both in the same document?

4.2.1.1: TMMBN is used without a definition.  It is defined a lot
earlier, but if we're defining TMMBR in 4.2.1, we should define TMMBN in
the same way on first reference.

4.2.1.1: "owner of the bandwidth limit" - this phrase is unclear to me.
4.2.1.1: "suppres" -> "suppress"
4.2.1.1: the paragraph beginning with "A media receiver..." is quite
confusing.

Aha, later in 4.2.1.1 it defines owner of bandwidth limits - after using
it.  But it's still confusing, perhaps because it seems like TMMBR/TMMBN
amount to a shared limit, not a "I want to receive" limit.  (I.e.
there's a single limit per session, which doesn't jibe with
Offer/Answer, which implies each participant has an independent
reception limit.)  Even with the shared limit, I still find the "owner"
concept confused.  Who starts out being the owner?  I note that TMMBN
starts with discussion of who an owner is.

4.2.1.1: SSRC timeout - could this lead to multiple entities in a
session believing they're the owner?  Race conditions?  

4.3.1.3 "onee" -> "one"

4.3.2: TSTR - I realize this is a "relative" request, and it makes sense
in the case of the multiply-mentioned "slider".  However, in some cases
a receiver may have a real need (or a real request) for a maximum or
specific framerate.  For example, if display hardware is 25fps, the UA
may wish to tell the sender that sending faster is wasted, instead of
having it try to guess or hunt for what Index value will yield the
desired framerate.  This point of control is sometimes (often) not
available at the signalling level.  We should (re?)consider absolute
requests (not requirements), both for preferred rates and for maximums.

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team [email-masked] "The fetters imposed on liberty at home have ever
been forged out of the weapons provided for defence against real,
pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

 
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 21 Dec 2006 07:34:36 +0200

Hi Randell,
thanks for your comments.  Nits will be fixed.  And the more  

> If nothing else, the above shows that the discussion of TMMBR needs

I think I see your point.  the "encode" is indeed misleading, and we  
can remove that.  However, that appears to me the only misleading  
sentence.  And no, TMMBR is not so much about "I don;t want to  
receive faster than X".  It is "I don't want to receive faster than X  
FROM YOU".  (It's per media sender, not per session).  In multicast,  
a single receiver can request such a bandwidth  reduction, which is  
observed by the sender for ALL receivers.  So, inherently, the effect  
of sending TMMBR messages appears to me a sender's property.
I'm not sure what to do about this comment further.  Could you  
suggest text that addresses your point?

> terminology used in other RFCs: "sender of a media stream".  (See  
"Media Stream" sounds SDP-ish.  Correct would perhaps something like  
"RTP packet stream conveying the media".  But I think that "media" is  
both sufficiently clear and concise enough not to overload the spec  
with unnecessary preciseness.  It's hard enough to read already.   
Perhaps we can settle by explaining what we mean with "sender of  
media" (and analogous terms) somewhere prominently at the begin of  
the doc?

> British
It's a mixture of Swenglish (Swedish English), Genglish (German  
English), and US English with the slightest Indian accent :-).   
Seriously, none of us authors are English native speakers.  Let's  
have the RFC editor worry about these details; it's their job.

> implemented the earlier drafts of RFC 4585 where Generic ACK was
I'm unaware of any product implementation of 4585 today, let alone  
the older drafts.  Implementation folks: is this a concern?  From a  
standardization viewpoint, it obviously isn't.

> there's a
The "Owner" concept has something to do with the algorithm that  
allows us to handle multicast, especially those cases in which the  
owner (i.e. media receiver that has sent the most restrictive  
bandwidth reduction requirement that has been received by the media  
sender) drops out of the session.  Before anyone has been sent a  
request, there is no owner.

> session
only if two media receivers sent identical (in value) TMMBR request  
at the "same time" -- in which case it does not matter who is the  
"Owner".

> for preferred rates and for maximums.
Not in this draft, please :-)
The can of worms you open when using RTCP as binding session control  
is just too large.  It would violate our design principles spelled  
out in section 4.1.

Regards,
Stephan

On Dec 12, 2006, at 3:39 AM, Randell Jesup wrote:

> earlier,
> British
> earlier,
> there's a
> session

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 21 Dec 2006 09:29:13 +0200

Stephan some more feedback

For everyone's reference, here the two para Roni suggests deleting:

   In so far, this memo follows the guidance of a decade of RTP payload

   format specification work -- the details of the media format carried

   is normally not described in any significant detail.

   However, we note that some H.271 messages bear similarities with

   native messages of AVPF and this memo.  Furthermore, we note that

   some H.271 message are known to require caution in multicast

   environments -- or are plainly not usable in multicast or multipoint

   scenarios.  Table 1 provides a brief, oversimplifying overview of the

   messages currenty defined in H.271, their similar AVPF or CCM

   messages (the latter as specified in this memo), and an indication of

   our current knowledge of their multicast safety.

I have no problems in removing the upper paragraph in lieu of the line Roni suggested.  However, the lower one has considerable information in it, and IMHo should stay.  Others?

RE:  My mistake in the comment. The replacement text was for the following text

I meant to remove the following part

"Another reason lies in the complexity of the H.271 specification: it

   is a dense document with currently 16 pages of content.   It does not

   make any sense to try to summarize its content in a few sentences of

   IETF lingo -- oversimplification and misguidance would be inevitable.

   Finally, please note that H.271 contains many statements of

   applicability and interpretation of its various messages in

   conjunction with specific video compression standards.  This type of

   discussion would overload the present memo.

   In so far, this memo follows the guidance of a decade of RTP payload

   format specification work -- the details of the media format carried

   is normally not described in any significant detail."

I don't get this remark.  Are you suggesting TMMBR is primarily for multipoint/cast?  No, it's not.  Part for the rush with the WGLC is that we have TMMBR in TS 26.114 (MTSI), which is point-to-point at present.  And the reliability discussion applies IMHO for both P2P and multipoint (of whatever kind); it's about what happens when you loose the RTCP RR carrying the message, and that can happen in all scenarios.  So could you please elaborate further what should be changed here?

RE: When reading the second paragraph I cannot see how it applies to point to point or MCU case since in those cases there is only participant requesting the BW change (the other party or the MCU)

 

________________________________

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 21 Dec 2006 07:02:01 +0200

Hi Roni,

thanks for the comments and nits.

The nits will go into the document.  As for the more substantial  
comments

> 5. In the terminology section " To the best of the author's  
> knowledge, the term "Decoder Refresh Point" has been formally  
> defined only in H.264; hence   we are referring here to this video  
> compression standard"
> I could not find this term I H.264 and it is not part of the ITU  
> terminology database in SANCHO - http://www.itu.int/sancho/index.asp
Yes, this has also already been spotted by others.  Will be fixed.   
It's terminology only, though (Independent Decoder Refresh Picture/ 
Slice is defined).

> and there is no reference.
Informative references to be added

> 13. In section 3.5.2 "Index values from 0 to 31 indicate  
> monotonically a desire for higher frame rate.". I am not sure what  
> this sentence means. Is 1 higher frame rate than 0. Also what is  
> the relation between frame rate and temporal and spatial  
> resolution. Maybe have the text from 4.3.2.1
I think the text is clear.  Could copy-paste and add redundancy, but  
is there really a need?  Anyone else has an opinion.  Btw., this is  
text from H.245 :-)

> 15. In section 3.5.2.4 third bullet, How does the sender know why  
> his request was not accepted  so he will not send repetitive  
> messages, maybe some text is needed saying that if in multicast or  
> multipoint the sender SHOULD NOT expect that his request will be  
> accepted and SHOULD NOT repeat it if acknowledged by a different  
> value.
Not sure about this.  I need to think a bit more, and perhaps Magnus  
has also an opinion here, but to me it appears that adding your  
remarks unnecessarily breaks the algorithm.  What's more approriate  
is perhaps a forward reference to the formal definition of TMMBR/TMMa  
in section 4.2.1

> 16. In section 3.5.3 I suggest adding "This memo addresses only the  
> transport of those code-points." To the second paragraph and delete  
> the next two paragraphs.

    However, we note that some H.271 messages bear similarities with
    native messages of AVPF and this memo.  Furthermore, we note that
    some H.271 message are known to require caution in multicast
    environments -- or are plainly not usable in multicast or multipoint
    scenarios.  Table 1 provides a brief, oversimplifying overview of  
the
    messages currenty defined in H.271, their similar AVPF or CCM
    messages (the latter as specified in this memo), and an  
indication of
    our current knowledge of their multicast safety.

I have no problems in removing the upper paragraph in lieu of the  
line Roni suggested.  However, the lower one has considerable  
information in it, and IMHo should stay.  Others?

> 22. Section 3.5.4.4 talks about reliability. I am not sure it is  
> applicable to point o point calls or to an MCU case. It is more for  
> multicast. If this it correct than it should say so.
I don't get this remark.  Are you suggesting TMMBR is primarily for  
multipoint/cast?  No, it's not.  Part for the rush with the WGLC is  
that we have TMMBR in TS 26.114 (MTSI), which is point-to-point at  
present.  And the reliability discussion applies IMHO for both P2P  
and multipoint (of whatever kind); it's about what happens when you  
loose the RTCP RR carrying the message, and that can happen in all  
scenarios.  So could you please elaborate further what should be  
changed here?

> 23. In section 4.2.1.1 you have " TMMBR feedback SHOULD NOT be used  
> if the underlying transport protocol is capable of providing  
> similar feedback information from the receiver to the sender.". Do  
> you mean that if using TCP you SHOULD NOT use TMMBR. TCP cannot  
> address the multipoint case described.
I don't recall the motivation for this sentence.  Magnus?

> 25. In section 4.2.1.2  " SSRC:   The SSRC value of the target of  
> this specific maximum bit-rate request." Who is the target, is it  
> the target for the media (the sender of the request) or the target  
> for the request.
Will be clarified

Regards,
Stephan

On Dec 11, 2006, at 3:36 PM, Even, Roni wrote:

> 2. In section 1 fifth paragraph "The Temporary Maximum Media  
> Bandwidth Request (TMMBR) Message allows to signal, from media  
> receiver to media sender, the current maximum supported media bit- 
> rate for a given media stream" suggest changing supported to requested
>
> 4. In the definition in glossary for TSTA is "Temporal Spatial  
> Trade-off Announcement" but according to the terminology it should  
> be a notification. Suggest either changing the name or defining  
> announcement as notification in the terminology section.
>
> 5. In the terminology section " To the best of the author's  
> knowledge, the term "Decoder Refresh Point" has been formally  
> defined only in H.264; hence   we are referring here to this video  
> compression standard"
> I could not find this term I H.264 and it is not part of the ITU  
> terminology database in SANCHO - http://www.itu.int/sancho/index.asp
>
> 9. In section 3.1 item 8 " It operates the receiver sending a  
> feedback message to the sender" should be "it operates by the ..."
>
> 10. In section 3.2 " The topological locations of the signalling  
> entities are also commonly not optimized for minimal delay, rather  
> other architectural goals." Suggest "delay, but rather for ..."
>
> 11. In section 3.2 "Furthermore, AVPF implements rules controlling  
> the timing of feedback messages  so to avoid congestion through  
> network flooding. We re-use these rules by referencing to AVPF."
> suggest
> "Furthermore, AVPF defines rules controlling the timing of feedback  
> messages avoiding congestion through network flooding. We re-use  
> these rules by referencing AVPF."
>
> 11. In section 3.5.1.1 second paragraph "timing rules the session  
> operates under" suggest "timing rules applicable to the session"
>
> 12. In section 3.5.1.1 third paragraph "and MCU to decoder refresh  
> point generating MCU". I think it should be "generating endpoint"
>
> 13. In section 3.5.2 "Index values from 0 to 31 indicate  
> monotonically a desire for higher frame rate.". I am not sure what  
> this sentence means. Is 1 higher frame rate than 0. Also what is  
> the relation between frame rate and temporal and spatial  
> resolution. Maybe have the text from 4.3.2.1
>
> 15. In section 3.5.2.4 third bullet, How does the sender know why  
> his request was not accepted  so he will not send repetitive  
> messages, maybe some text is needed saying that if in multicast or  
> multipoint the sender SHOULD NOT expect that his request will be  
> accepted and SHOULD NOT repeat it if acknowledged by a different  
> value.
>
>
> 16. In section 3.5.3 I suggest adding "This memo addresses only the  
> transport of those code-points." To the second paragraph and delete  
> the next two paragraphs.
>
> 19. In section 3.5.4 4th paragraph "as negotiated during  
> signalling." Suggest "as negotiated using call signalling."
>
> 21. In section 3.5.4.1 towards the end "and hence needs explicitly  
> informed about desired bandwidth adjustments" suggest "needs to be  
> explicitly ..."
>
> 22. Section 3.5.4.4 talks about reliability. I am not sure it is  
> applicable to point o point calls or to an MCU case. It is more for  
> multicast. If this it correct than it should say so.
>
> 23. In section 4.2.1.1 you have " TMMBR feedback SHOULD NOT be used  
> if the underlying transport protocol is capable of providing  
> similar feedback information from the receiver to the sender.". Do  
> you mean that if using TCP you SHOULD NOT use TMMBR. TCP cannot  
> address the multipoint case described.
>
> 24. in section 4.2.1.1 " If the value set by a TMMBR message is  
> expected to be permanent the TMMBR setting party is RECOMMENDED to  
> renegotiate the session parameters to reflect that using the setup  
> signalling." Suggest call signaling and not setup
>
> 25. In section 4.2.1.2  " SSRC:   The SSRC value of the target of  
> this specific maximum bit-rate request." Who is the target, is it  
> the target for the media (the sender of the request) or the target  
> for the request.
>
> 26. In section 4.2.2.1, I think that most of the text applies to  
> multicast. Does all this apply to uni-cast?
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Dec 2006 10:19:44 +0100

Stephan Wenger skrev:

>> 23. In section 4.2.1.1 you have " TMMBR feedback SHOULD NOT be used if 
>> the underlying transport protocol is capable of providing similar 
>> feedback information from the receiver to the sender.". Do you mean 
>> that if using TCP you SHOULD NOT use TMMBR. TCP cannot address the 
>> multipoint case described.

The reason is that if the underlying transport has the functionality 
then it is unnecessary to duplicate it in the applications layer. And in 
the case of TCP, it clearly doesn't have the functionality you need in a 
multi-point case, thus the SHOULD NOT doesn't apply.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Dec 2006 16:30:02 -0500

Stephan Wenger <[email-masked]> writes:
>Hi Randell,
>thanks for your comments.  Nits will be fixed.  And the more  substantial
>stuff:

Thanks.  Sorry for not commenting earlier.

>> decode)".  I'm not certain that's the case.  From RFC 3264
>> (Offer/Answer): "If the bandwidth attribute is present for a stream, it
>> indicates the desired bandwidth that the offerer would like to receive"
>> and "It SHOULD send media using a bandwidth no higher than the value of
>> the bandwidth attribute in the offer, if any was present."
>>
>I think I see your point.  the "encode" is indeed misleading, and we  can
>remove that.  However, that appears to me the only misleading  sentence.
>And no, TMMBR is not so much about "I don;t want to  receive faster than
>X".  It is "I don't want to receive faster than X  FROM YOU".  (It's per
>media sender, not per session).  In multicast,  a single receiver can
>request such a bandwidth  reduction, which is  observed by the sender for
>ALL receivers.  So, inherently, the effect  of sending TMMBR messages
>appears to me a sender's property.
>I'm not sure what to do about this comment further.  Could you  suggest
>text that addresses your point?

I always think in terms of unicast, and 2-party unicast at that.  :-)

While the TMMBR says "I don't want to receive faster than X  FROM YOU",
it's merely a notification to the sender, which can then do what it wants
with the information (including doing nothing), so I wouldn't say it's
a "senders property".

Specific wording where it talks about what the bitrate from signaling
means (replacing the quoted sentence fragment above): "the bit-rate
signaled is the rate that the participant desires to receive; a sender
should send media to the participant at that rate or below per [RFC 3264]."

In the next paragraph, "between 0 and the session maximum, as negotiated
during signaling" should become "between 0 and the desired bit-rate
signaled by that participant"

In 3.5.4.3, I'd change "session and media bit-rates" to "session and/or
media receive bit-rates".  The and/or may not be needed, but I was worried
about implying that both are always signalled.  (Plus I'm unclear here what
"media bit-rate" means - is it payload-specific?  Or is it per-stream?
Does "media bitrate" include RTP/UDP/IP overhead?  (Since the use of the
word media implies that it doesn't...).)

Also, in 4.2.1.1, references similar to "reset it to the session limit"
should change, for example to "reset it to the desired reception bit-rate
signaled by that participant".

>> 3264,
>"Media Stream" sounds SDP-ish.  Correct would perhaps something like  "RTP
>packet stream conveying the media".  But I think that "media" is  both
>sufficiently clear and concise enough not to overload the spec  with
>unnecessary preciseness.  It's hard enough to read already.   Perhaps we
>can settle by explaining what we mean with "sender of  media" (and
>analogous terms) somewhere prominently at the begin of  the doc?

The problem is that readers (as per my last comment above) may
mis-interpret "media" as something other than "RTP packet stream conveying
the media" - in fact, the way you used "media" in that implies that it's
contained within the RTP stream, but that it isn't the entire stream.  Does
the bit-rate restriction apply to all RTP data including overhead,
RTP-NOOP's, header extensions, alternative codecs, etc, or does it just
apply to packets that convey "media", or does it just apply to the payloads
within the RTP packets?

Implementors DO mis-read this sort of thing and then we get into a horrid
mess where we have to sniff SIP/etc to guess who sent us the b= line, so we
can 'adjust' the value they sent to compensate for their mis-understanding
the spec.  I'd rather waste words and be specific and clear.

How about "RTP packet stream"?  In this case, for example 4.2.1.1, "highest
bit-rate per sender of an RTP packet stream".

>It's a mixture of Swenglish (Swedish English), Genglish (German  English),
>and US English with the slightest Indian accent :-).   Seriously, none of
>us authors are English native speakers.  Let's  have the RFC editor worry
>about these details; it's their job.

Sure.

>I'm unaware of any product implementation of 4585 today, let alone  the
>older drafts.  Implementation folks: is this a concern?  From a

We have had an implementation of RFC 4585 in the field for ~2 years (around
1.5 years longer than it's been an RFC).  We never used Generic ACK, but
my question was if anyone else had.  Lots of RFCs get implemented and
fielded while still in draft stage, and removal of FMT=2 was very late in
the RFC process if I remember.

>> it.  But it's still confusing, perhaps because it seems like TMMBR/ TMMBN
>The "Owner" concept has something to do with the algorithm that  allows us
>to handle multicast, especially those cases in which the  owner (i.e. media
>receiver that has sent the most restrictive  bandwidth reduction
>requirement that has been received by the media  sender) drops out of the
>session.  Before anyone has been sent a  request, there is no owner.

I think it would help a lot to spell out this "owner concept" *before* it's
used, and to spend a little more verbiage explaining it and what it does.
Right now it's spelled out well after it's used.  At minimum a forward
reference is needed.

>only if two media receivers sent identical (in value) TMMBR request  at the
>"same time" -- in which case it does not matter who is the  "Owner".

Actually, the TMMBN indicates who the new owner is, so one of them will
'win'.

>The can of worms you open when using RTCP as binding session control  is
>just too large.  It would violate our design principles spelled  out in
>section 4.1.

Well, no "binding" session control was indicated there - though all of the
AVPF messages verge on a form of session control.

A maximum decode rate is often signalled.  However, a preferred/maximum
frame rate (if you like, a slider with absolute numbers instead of
unit-less numbers) is certainly a valid thing to *request*, just as a
unit-less tradeoff is a request.  I actually find the unit-less tradeoff
very counter-intuitive from a user-interface point of view.  Part of the
problem is that there's no idea where you're starting (bottom, top,
middle), so any initial adjustment may produce confusing results (you may
move the "slider" up, but have the frame rate actually drop because the
slider position didn't match the encoder's default setting).

---

From: Keith Lantz <[email-masked]>
Date: Fri, 29 Dec 2006 14:14:29 -0800

Concur with most of Roni's and Randell's previous comments. Here are 
some additional ones. (That is, I hope they're mostly "additional", 
rather than "redundant".)

- In general, the "Introduction" seems to be much beefier than the 
average I-D or RFC -- constituting much more of an "executive 
summary" than is the norm. I don't have a particular problem with 
that ... other than it being unexpected.

         More concretely:

         In the first paragraph: "lied" --> "lay".

         In the 4th paragraph: "may become helpful also" --> "may 
also prove helpful"

         In the last paragraph: "The receiver of the video stream 
generates this signal typically based on input from its user 
interface, so to react to"
         --> "Typically, the receiver of the video stream generates 
this signal based on input from its user interface, in reaction to"

- p. 9, definition of Decoder Refresh Point: "author's knowledge" --> 
"authors' knowledge" (since there are multiple authors

         definition of Stream Thinning: "performed media aware" --> 
"media-aware". Yes, drop the "performed" altogether. Second choice: 
"performed in a media-aware fashion".

- p. 11, item 7: Like other reviewers I'm not quite sure what "used 
congestion control algorithms" means. Perhaps you need to be 
specific, e.g. "The congestion control algorithms used in <x> and <y> 
(AMID and TFRC, respectively) probe ..."

         Insert comma after "Thus" in "Thus indicating ..."

         Finally, the last sentence of that list item is broken. I 
think you're trying to say the following: "To minimize disruption of 
service, especially in reduced-bandwidth environments, quick 
convergence is desired. This suggests the use of media path signalling." (???)

- pp. 11f, item 8: The second sentence is broken. Potential rewrite: 
"It provides for a receiver to send a feedback message to the sender, 
identifying a reference picture that should be used for future prediction."

- p. 13, Section 3.4 (& probably elsewhere): Hyphenate "media related".

- p. 14, end of first paragraph: "participants request" --> 
"participant's request"
         "Thus suppressing" --> "Suppressing"

- p. 15, Section 3.5.2: As noted by others, TSTA should be *clearly* 
defined, up front, in an analogous fashion to "Temporal Spatial 
Trade-off Request (TSTR)". As written, one is left wondering whether 
the "A" stands for "acknowledgement" or "announcement" ... until page 
17, when "Temporal Spatial Trade-off Announcement (TSTA)" finally appears.

         Also, hyphenate "implementation specific". (Indeed, 
virtually all occurrences of "<x> aware", "<y> specific", "<z> 
related", etc. should be hyphenated.)

- p. 17, Section 3.5.3: "The perhaps" --> "Perhaps the"

         "In so far" --> "In any event"

- p. 19, list item 4: "not multicast save" --> "non-multicast-safe"

- p. 21, 2nd paragraph of Section 3.5.4.1: Per my previous comment, 
"if performed media aware" --> "if media-aware".

         Correspondingly, "If done media unaware" --> "If 
media-unaware" ... or "media-transparent".

- p. 23: Insert commas after
         "However" (first line)
         "Therefore" (2nd sentence of 3.5.4.4)
         "In addition" (5th sentence of 3.5.4.4)
         "Otherwise" (last sentence)

- p. 24, Section 4: The formal name and abbreviation for TMMBN 
appears for the first time in this section. Clearly, they should be 
introduced somewhere in 3.5.4.

- p. 25, Section 4.2: "value RTPFB" looks wrong. It's certainly 
inconsistent with the analogous treatment for other messages -- in Section 4.3.

        Insert comma after "two more messages".

- p. 26: "suppres" --> "suppress"

         Delete (!) comma from "bandwidth limit, MAY".

- p. 27: "It also important" --> "It is also important".

         "larger number" --> "large number"

         "Larger session" --> "Large sessions"

- p. 31, last paragraph: "reference pictures in encoder and decoder" 
--> "reference pictures in the encoder and decoder"

         "PLI, for example if" --> "PLI, for example, if"

- p. 32: "a typical example" --> "A typical example"
         and "adequate" --> "appropriate"

- p. 34, 2nd line: "particular short delay" --> "particularly short delay".

- p. 38, first paragraph: "codec specific" --> "codec-specific" (;-))

         More importantly, the second sentence needs help. Suggested 
rewrite: "The type of feedback information can be classified as a 
'status report' (such as receiving bit stream without errors, or loss 
of partial or complete picture or block) or an 'update request' (such 
as a complete refresh of the bit stream)."

- p. 40: Section numbers are missing from "Timing Rules" (should be 
4.3.4.3) and "Remarks" (should be 4.3.4.4).

- p. 40, Section 5: "network flooding" --> "network from being flooded"

- p. 41, Section 6: "there is need" --> "there is a need"

         More importantly, what are "group-external" threats?

- p. 42, Section 7.1: The third sentence is broken ... and I can't 
parse it well enough to propose a rewrite.

         "rtcp-fb attributed as defined" --> "rtcp-fb as defined".

- p. 43, Section 7.2: "to as described" --> "those described"

         Remove the comma from "all ccm parameters, which".

- pp. 43ff, Section 7.3: Be consistent in the way you "name" the 
various codec control messages in the introductory paragraphs for 
each example. As it stands, some are capitalized, some are not, and 
some are quoted. They should all be capitalized, without quotes.

Regards, Keith

----------------
Keith Lantz, Ph.D.                        Voice: +1 (408) 902-3302
Cisco Distinguished Engineer              FAX:   +1 (408) 525-4971
Office of the CTO                         Email: klantz (at) cisco.com
Voice Technology Group
Cisco Systems, Inc.