Subject: Re: [AVT] more comments on draft-ietf-avt-avpf-ccm-03

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 12:49:04 +0200

Hi Keith,

thanks for these four (!) pages of comments and nits, which will go  
into the updated draft version I surely expect to be necessary.  Let  
me also apologize for not addressing these nits earlier.  (Keith did  
communicate most of them already during the -00 timeframe).  One remark:

On Dec 30, 2006, at 12:14 AM, Keith Lantz wrote:
> - p. 25, Section 4.2: "value RTPFB" looks wrong. It's certainly  
> inconsistent with the analogous treatment for other messages -- in  
> Section 4.3.
Both 205 and 206, in sections 4.2 and 4.3 respectively,  are  
correct.  They are defined in RFC 4585 section 6.1.  I have added  
appropriate references to avoid future confusion.

Regards,
Stephan

>
>        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.
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 13:53:50 +0200

Hi Randell, all,
I'm editing the draft, but before I start making substantial changes  
in response to your comments, let's sort out the nature of the  
changes first.  I'm breaking the original email thread up so to make  
it more manageable.  Here's the first (about section 3.5.4.  
reproduced below for convenience:

--- SNIP ---
3.5.4.      Temporary Maximum Media Bit-rate Request

    A receiver, translator or mixer uses the Temporary Maximum Media  
Bit-
    rate Request (TMMBR, "timber") to request a sender to limit the
    maximum bit-rate for a media stream to, or below, the provided  
value.
    The primary usage for this is a scenario with MCU (use case 6),
    corresponding to Topo-Translator or Topo-Mixer, but also Topo-Point-
    to-Point.

    The temporary maximum media bit-rate messages are generic messages
    that can be applied to any media.

    The reasoning below assumes that the participants have negotiated a
    session maximum bit-rate, using the signalling protocol. This value
    can be global, for example in case of point-to-point, multicast, or
    translators.  It may also be local between the participant and the
    peer or mixer. In both cases, the bit-rate negotiated in signalling
    is the one that the participant guarantees to be able to handle
    (encode and decode).  In practice, the connectivity of the
    participant also bears an influence to the negotiated value -- it
    does not necessarily make much sense to negotiate a media bit rate
    that one's network interface does not support.

    An already established temporary bit-rate value may be changed at  
any
    time (subject to the timing rules of the feedback message sending),
    and to any value between zero and the session maximum, as negotiated
    during signalling. Even if a sender has received a TMMBR message
    increasing the bit-rate, all increases must be governed by a
    congestion control algorithm. TMMBR only indicates known  
limitations,
    usually in the local environment, and does not provide any
    guarantees.

    If it is likely that the new bit-rate indicated by TMMBR will be
    valid for the remainder of the session, the TMMBR sender can perform
    a renegotiation of the session upper limit using the session
    signalling protocol.
--- SNIP ---

On Dec 21, 2006, at 11:30 PM, Randell Jesup wrote:

> 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.
>
>>> 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.
>>
>> 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]."

I don't understand the reference to 3264 here.  Let me make a counter- 
proposal:
"the bit-rate is the rate that the participant desires to receive  
from the
sender identified in the message.  A media sender should send media
at that rate or at a lower rate."

> 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"

No, the sentence in the draft is correct.  We explicitly allow that  
the media
receiver which has established a certain limit, can raise that limit  
again.

>
> In 3.5.4.3, I'd change "session and media bit-rates" to "session  
> and/or
> media receive bit-rates".

Should be OK.

> The and/or may not be needed, but I was worried
> about implying that both are always signalled.

No need to do anything here, I guess.

> (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...).)

With respect to this, I suggest to fix it in the definitions  
somewhere.  Media bitrate ==
the bitrate of an RTP stream (which normally carries media).

>
> 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".

No, session limit seems fine to me.  It covers cases where multiple  
senders listen
to each other's bandwidth usage and adjust their respective behavior  
to what
the other senders to (up to the session limit, which applies for all  
senders in
combination.
The main problem with your text is that (at least in theory and in  
multi-sender multicast)
a media sender is bound to a session limit which it has never signaled.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 14:02:22 +0200

Here's the second chunk.
Stephan

[...]
>
>>> 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).
>> "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?

It applies to the bandwidth utilized by the codec data, excluding  
packetization
overhead.  You don't know the packetization overhead, as you don't know
whether you are running IPv4, IPv6, RoHC (and its state), etc. etc.   
At least
that's my recollection.  We had long discussions about this between us
authors.
I believe the bitrates in SDP and friends have similar semantics.
I agree that we should clarify this prominently in the draft, but I  
continue
to be against over-precise (and difficult to read) language.

>
> 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".

For the reasons above you don't want to signal the bandwidth of the  
packet
stream...  if standardization forces implementers to worry about a  
codec rate
control that worries about RoHC states, no one will implement it anyway.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 14:08:31 +0200

And the third:

On Dec 21, 2006, at 11:30 PM, Randell Jesup wrote:

>
>>> 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.
>> 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.

Agreed.  How about a short informative discussion in section 3.5.4 or
thereabouts?  We can even include a sentence to the extend "If you
are not in multicast, you can forget this whole paragraph and change
your TMMBR bitates up or down to your hearts content (subject only to
session limit as signaled and your RTCP bandwidth limits)."

>
>>> 4.2.1.1: SSRC timeout - could this lead to multiple entities in  
>>> a  session
>>> believing they're the owner?  Race conditions?
>> 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'.

Right.  Still, there's no problem here, or am I wrong.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 14:16:54 +0200

Part four.
Stephan

On Dec 21, 2006, at 11:30 PM, Randell Jesup wrote:

>
>>> 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.
>>
>> 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.
>
> 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).
>

Personally, I could entertain the idea of a "desired frame rate"  
feedback
message.  Propose it, and you have my support.  We have enough numbering
space for both.  But don't propose it in any binding sense, i.e. a media
sender MUST NOT exceed that frame rate because otherwise the receiver
may crash.  That would be session control and is against the design
principles mentioned.  And please propose it in another draft; we  
need CCM
in 3GPP soon.
I want to keep TSTR/TSTA for the key reason that it's used in practice.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 5 Jan 2007 14:20:16 +0200

Folks,
in the context of the WGLC of the CCM draft, the following discussion  
ensued:

>
>>> 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?
>> 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.
>
> 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.
>

Please speak up.

Question to the WG: we have numbering space available.  Should we pro- 
actively
NOT use FMT=2 for the TMMBR message, and select something else instead?

Thanks,
Stephan

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Jan 2007 16:07:40 -0500

Stephan Wenger <[email-masked]> writes:
>>>> 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?
>>> I'm unaware of any product implementation of 4585 today, let  alone  the
>> (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.
>
>actively NOT use FMT=2 for the TMMBR message, and select something else
>instead?

For cases like this, I'm usually tempted to avoid re-using an enum that
might have been used until I've used most or all the other values
available.  It's not like FMT=2 was in an early draft and quickly went
away; I think it was in all drafts until the last revision or two.
Asking is good.  If there's any question, in my mind avoiding a possible
collision is good too.  Not a huge issue either way; I just like to play
it safe when drafts go on for years before final changes and RFCing.

-- 
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: Randell Jesup <[email-masked]>
Date: Fri, 05 Jan 2007 16:51:17 -0500

Stephan Wenger <[email-masked]> writes:

>Hi Randell, all,
>I'm editing the draft, but before I start making substantial changes  in
>response to your comments, let's sort out the nature of the  changes first.
>I'm breaking the original email thread up so to make  it more manageable.
>Here's the first (about section 3.5.4.  reproduced below for convenience:
>
>--- SNIP ---
>    A receiver, translator or mixer uses the Temporary Maximum Media  Bit-
>    maximum bit-rate for a media stream to, or below, the provided  value.
>    An already established temporary bit-rate value may be changed at  any
>    congestion control algorithm. TMMBR only indicates known  limitations,
>>>> In 3.5.4, it states that "the bit-rate negotiated in signalling  is the
>>>> (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
>>>> that bandwidth specs are for reception and say nothing about how   fast
>>>> an
>>>> TMMBR appears to me to be "I don't want to receive faster than  X", but
>>>> about encode and "session maximum" appear to be at least  confusing when
>>>> 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
>>> 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
>>> request such a bandwidth  reduction, which is  observed by the  sender
>>> for
>>> I'm not sure what to do about this comment further.  Could you   suggest
>> 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
>I don't understand the reference to 3264 here.

Search it for "bandwidth".  Example:
   If the bandwidth attribute is present for a stream, it indicates the
   desired bandwidth that the offerer would like to receive.  A value of
   zero is allowed, but discouraged.  It indicates that no media should
   be sent.  In the case of RTP, it would also disable all RTCP.

>Let me make a counter-proposal:
>"the bit-rate is the rate that the participant desires to receive  from the

One problem is that this sounds like a mandate to send at or below that
rate (though it does say "should"), and there's no reference to 3264 (3264
makes sense since it's the same sort of bandwidth setting we're talking
here, but done at the negotiation phase).  I'm ok with your phrasing (it's
definitely better than the original), though I'd like a ref to 3264 if
possible, and it may make sense to add something like "if possible", or
"but is not required to", etc, to avoid misunderstandings.  Not critial,
though.

>> In the next paragraph, "between 0 and the session maximum, as  negotiated
>No, the sentence in the draft is correct.  We explicitly allow that the
>media receiver which has established a certain limit, can raise that limit
>again.

Ok, I see what you're saying, though I think you missed my point.  "Session
maximum" is a broken term which implies a two-way agreed max; there is no
session maximum, there's an "initial desired reception bit-rate" for a UA.
That's why I said "desired bit-rate signalled by that participant".  That
means you can raise it again, though no higher than the value you indicated
in signalling.  Note that we should cover the case of no value signalled,
in which case you can set the desired reception rate to anything you want.

>> Does "media bitrate" include RTP/UDP/IP overhead?  (Since the use  of the
>With respect to this, I suggest to fix it in the definitions  somewhere.
>Media bitrate ==

>From RFC 4566 and RFC 3550, it appears that b=AS includes RTP and IP/UDP
headers, but NOT link-layer headers:

RFC 3550 6.2:
   Bandwidth calculations for control and data traffic include lower-
   layer transport and network protocols (e.g., UDP and IP) since that
   is what the resource reservation system would need to know.  The
   application can also be expected to know which of these protocols are
   in use.  Link level headers are not included in the calculation since
   the packet will be encapsulated with different link level headers as
   it travels.

>> 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
>senders listen to each other's bandwidth usage and adjust their respective
>behavior to what the other senders to (up to the session limit, which
>applies for all senders in combination.  The main problem with your text
>is that (at least in theory and in multi-sender multicast) a media sender
>is bound to a session limit which it has never signaled.

Perhaps, but here are my assumptions; correct me if I'm wrong:
a) A participant signals bandwidth with b=AS:<value>.  That is their
   desired *reception* bitrate per RFC 4566 and RFC 3264.
b) TMMBR says that the sending participant wants to receive (from this
   sender) at a bitrate equal to or lower bitrate than the signalled one
   (if one was signalled).

I'll freely admit that I don't fully grok the details of multicast
bandwidth allocation and negotiation.

If my assumptions are right, my text should be correct - reset it to the
initial desired (signalled) value, as if the desired bandwidth had not been
reduced temporarily.

There may be a fundamental tension here between multicast negotiation and
allocation and unicast negotiation.  Also note I'm assume b=AS, not b=CT.
I've never seen b=CT in the wild, though I imagine it's used.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Jan 2007 16:57:11 -0500

Stephan Wenger <[email-masked]> writes:

>>>> 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).
>>> "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?
>>
>> 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?
>
>packetization overhead.  You don't know the packetization overhead, as you
>don't know whether you are running IPv4, IPv6, RoHC (and its state),
>etc. etc.  At least that's my recollection.  We had long discussions about
>this between us authors.  I believe the bitrates in SDP and friends have
>similar semantics.  I agree that we should clarify this prominently in the
>draft, but I continue to be against over-precise (and difficult to read)
>language.

I just looked it up in my previous message - bandwidth per RFC 4566
referencing RFC 3550#6.2 includes IP/UDP (if used - RFC 3550 says it
assumes the application knows what's used) and RTP headers, but not
link-layer.

Personally, I scratched my head for minutes trying to figure out what a
singular "media" was.

>> 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.
>>
>> "highest bit-rate per sender of an RTP packet stream".
>
>For the reasons above you don't want to signal the bandwidth of the packet
>stream...  if standardization forces implementers to worry about a codec
>rate control that worries about RoHC states, no one will implement it
>anyway.

But per above we ARE signalling the bandwidth of a packet stream.  That is
the way it is defined now.  If we need to change that, that's a separate
issue.  RFC 3550 assumes the application understands what IP/UDP/RTP header
stuff is going on.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Jan 2007 17:04:00 -0500

Stephan Wenger <[email-masked]> writes:
>> 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.
>

Sure (modulo "session limit" language).

>>>> 4.2.1.1: SSRC timeout - could this lead to multiple entities in  a
>>>> session
>>> only if two media receivers sent identical (in value) TMMBR  request  at
>>> the
>> Actually, the TMMBN indicates who the new owner is, so one of them  will
>> 'win'.
>

I think we're ok there, though it may not be obvious to the reader.  I
missed it initially.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Jan 2007 17:07:56 -0500

Stephan Wenger <[email-masked]> writes:
>> A maximum decode rate is often signalled.  However, a preferred/ maximum
>> 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
>> middle), so any initial adjustment may produce confusing results  (you may
>> move the "slider" up, but have the frame rate actually drop because  the
>Personally, I could entertain the idea of a "desired frame rate"  feedback
>principles mentioned.  And please propose it in another draft; we  need CCM
>in 3GPP soon.

Ok, though I suspect (pretty much know) I won't have time to create and
husband a draft into an RFC myself - I spend my days implementing stuff,
and this IETF stuff is mostly just a little relaxation. :-) I'll try to
tack it onto the next CCM draft, whenever that is.

>I want to keep TSTR/TSTA for the key reason that it's used in practice.

Sure.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 6 Jan 2007 09:21:31 +0000

> it safe when drafts go on for years before final changes and RFCing.

Agreed. We have space - let's avoid reusing the old code unless  
necessary.

Colin

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 6 Jan 2007 16:19:48 +0200

Ok.  Will be implemented.
Stephan

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 6 Jan 2007 16:27:15 +0200

Hi Randell, folks,

in response to this thread, I have added a new section 3.5.4.1.  
(right after the intro to TMMBR and TMMBN).  Do that level of detail  
sound about right?
Stephan

>           3.5.4.1. Algorithm for exstablishing new maximum bit rates
>
>
> In multicast scenarios, different receivers likely have different  
> preferences for receiving bandwidth.  Therefore, a simple algorithm  
> is specified in section 4.2.2.1to identify the most restrictive  
> TMMBR request.  The gist of that algorithm is explained informally  
> below.
>
> Immediately after session setup, the bandwidth limit is set to the  
> session limit as established by the control protocol.
>
> At any given time, a media receiver can send a TMMBR with a  
> bandwidth limit that is lower than the current limit.  Once the  
> media sender has sent the TMMBN message, the receiver indicated in  
> that message becomes the ``owner’’ of the limitation.  Most likely,  
> the owner is the original sender of the TMMBR -- for the handling  
> of corner-cases (i.e. concurrent TMMBRs from different receivers,  
> lost TMMBRs and so on) please see the formal specification.   
> ``Owner’’ and bandwidth limit are known session wide, as both TMMBR  
> and TMMBN are multicasted.
>
> Only the ``owner’’ is allowed to raise the bandwidth limit to a  
> value higher than it has been notified of.  The ``owner’’ does not  
> need to take into account TMMBR messages sent by anyone else  
> (although that may well be a desirable optimization).  If the  
> ``owner’’ sets the new session limit that is too high for someone  
> else’s liking, other media receivers can react to the situation by  
> emmmitting their own TMMBR message (and, in the process, become  
> ``owner’’).
>
> Obviously, when there is only one media receiver, this receiver  
> becomes ``owner’’ once it receives the first TMMBN in response to  
> its own TMMBR, and stays ``owner’’ for the rest of the session.   
> Therefore, when it is known that there will always be only a single  
> media receiver, the above algorithm is not required.  Media  
> receivers can send TMMBR messages with bandwidth limits both higher  
> and lower than the previously notified limit at any time (subject  
> to AVPF’s RTCP RR send timing rules).

On Jan 6, 2007, at 12:04 AM, Randell Jesup wrote:

>>> *before*
>>>> request  at

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 6 Jan 2007 16:28:38 +0200

So, I guess we can consider that comment closed :-)
Stephan

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 7 Jan 2007 16:42:07 +0200

Hi,
>From RFC3264 section 6.1

"It SHOULD send media using a bandwidth no higher than the value of the
bandwidth attribute in the offer, if any was present."

The BW value for codec that has fixed size frames will be constant.
Video does not have a constant bit rate and this is one of the reasons
for the SHOULD and why it is an upper limit.

My understanding of TMMBR is that the receiver will request a bandwidth
lower or higher than the current one as long as it does not go over the
BW allocated in the signaling protocol like the SDP definition in SIP

Roni

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: Friday, January 05, 2007 11:51 PM
> To: Stephan Wenger
> Cc: Even, Roni; [email-masked]
> Subject: Re: CCM draft, Randell's comments, part 1
> 
in
> >>>> In 3.5.4, it states that "the bit-rate negotiated in signalling
is
> >>>> (Offer/Answer): "If the bandwidth attribute is present for a
stream,
> it
value
> of
> fast
X",
> but
confusing
> when
rate
> >>>> bit-rate" or equivalent, which implies a shared limit apparently
not
> in
we
> >>> And no, TMMBR is not so much about "I don;t want to  receive
faster
> than
(It's
> per
sender
> >"the bit-rate is the rate that the participant desires to receive
from
the
> >> Does "media bitrate" include RTP/UDP/IP overhead?  (Since the use
of
> >With respect to this, I suggest to fix it in the definitions
somewhere.
> >> should change, for example to "reset it to the desired reception
bit-
> rate
> 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."

---

From: Randell Jesup <[email-masked]>
Date: Sun, 07 Jan 2007 10:49:40 -0500

>for the SHOULD and why it is an upper limit.

Video is typically variable bitrate, but a given stream may have a lower
limit that the UA will do or lower effective limit due to quality (or even
a fixed bitrate if it's pre-encoded).  Even in initial signalling, the
bitrate is a SHOULD - it's not an upper limit (which would be MUST).  Note
that the discussion you're responding to talks to the TMMBR bitrate request
and whether that reduced bitrate is a mandate or a request.

>BW allocated in the signaling protocol like the SDP definition in SIP

Yes.  If no bandwidth spec was in the signalling, there's no limit on
what TMMBR can request.

>> >Let me make a counter-proposal: "the bit-rate is the rate that the
>> >participant desires to receive from the sender identified in the
>> >message.  A media sender should send media at that rate or at a lower
>> >rate."
>> 
>> rate (though it does say "should"), and there's no reference to 3264
>> (3264 makes sense since it's the same sort of bandwidth setting we're
>> talking here, but done at the negotiation phase).  I'm ok with your
>> phrasing (it's definitely better than the original), though I'd like a
>> ref to 3264 if possible, and it may make sense to add something like "if
>> possible", or "but is not required to", etc, to avoid misunderstandings.
>> Not critial, though.
>> 
>> >> negotiated during signaling" should become "between 0 and the desired
>> >> bit-rate signaled by that participant"
>> >
>> >media receiver which has established a certain limit, can raise that
>> >limit again.
>> 
>> Ok, I see what you're saying, though I think you missed my point.
>> "Session maximum" is a broken term which implies a two-way agreed max;
>> there is no session maximum, there's an "initial desired reception
>> bit-rate" for a UA.  That's why I said "desired bit-rate signalled by
>> that participant".  That means you can raise it again, though no higher
>> than the value you indicated in signalling.  Note that we should cover
>> the case of no value signalled, in which case you can set the desired
>> reception rate to anything you want.
>> 
>> >> (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...).)
>> >
>> >Media bitrate == the bitrate of an RTP stream (which normally carries
>> >media).
>> 
>>    the packet will be encapsulated with different link level as
>>    it travels.
>> 
>> >> limit" should change, for example to "reset it to the desired
>> >> reception bit- rate signaled by that participant".
>> >
>> >senders listen to each other's bandwidth usage and adjust their
>> >respective behavior to what the other senders to (up to the session
>> >limit, which applies for all senders in combination.  The main problem
>> >with your text is that (at least in theory and in multi-sender
>> >multicast) a media sender is bound to a session limit which it has
>> >never signaled.
>> 
>> initial desired (signalled) value, as if the desired bandwidth had not
>> been reduced temporarily.
>> 
>> There may be a fundamental tension here between multicast negotiation
>> and allocation and unicast negotiation.  Also note I'm assume b=AS, not
>> b=CT.  I've never seen b=CT in the wild, though I imagine it's used.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 8 Jan 2007 09:46:21 +0200

Randell,
 I am not sure I understand what the difference between a request and a
mandate is. My view is that a request is a command and not an
indication. TMMBR is typically used for video and sending reduce rate
TMMBR is a request or command to the sender not to send higher rate than
requested.

As for not signaling BW, I would strongly recommend a terminal that
wants to receive video to signal it since otherwise it may get a rate it
cannot decode. BTW, the upper BW may be signaled also by the level
parameter for H.264 and H.263

Roni

> Sent: Sunday, January 07, 2007 5:50 PM
> To: Even, Roni
> Cc: Stephan Wenger; [email-masked]
> >> ref to 3264 if possible, and it may make sense to add something
like
> "if
> >>    application can also be expected to know which of these
protocols
> are
> >>    sender) at a bitrate equal to or lower bitrate than the
signalled
> one
> >> If my assumptions are right, my text should be correct - reset it
to
OS
the
from

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 13:13:17 +0200

Side note:

On Jan 8, 2007, at 9:46 AM, Even, Roni wrote:

> [...]  BTW, the upper BW may be signaled also by the level

This is yet another limit; something that's even more hard-coded then  
the session maximum in offer-answer.  The processing requirements in  
the level definition tell you what the decoder guaranties to be able  
to process -- and are is many cases considerably higher than what  
your access link supports.  Beyond that, while many committees do  
support the levels as defined by the media standard committees,  
others don't -- and that's where levels become close to completely  
useless.

Suggest we leave this rather scary thing out of the discussion.

Stephan

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 8 Jan 2007 13:27:20 +0200

Stephan,
I was just trying to point out that even if there is no explicit BW
parameter in the SDP there may be an implicit one like as part of the
level parameter in H.264.
I still think that a good implementation SHOULD give the maximum BW it
can decode or receive on the link.
Roni

> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Monday, January 08, 2007 1:13 PM
> To: Even, Roni
> Cc: Randell Jesup; [email-masked]
> Subject: Re: [AVT] RE: CCM draft, Randell's comments, part 1
> Importance: Low
> 
> Side note:
> 
> >>> "It SHOULD send media using a bandwidth no higher than the value
of
> >> limit that the UA will do or lower effective limit due to quality
(or
> > even
> >> bitrate is a SHOULD - it's not an upper limit (which would be
MUST).
> > Note
> >>> lower or higher than the current one as long as it does not go
over
> >>>> One problem is that this sounds like a mandate to send at or
below
> > that
> >>>> bit-rate" for a UA.  That's why I said "desired bit-rate
signalled
> > by
> >>>>    in use.  Link level headers are not included in the
calculation
> >> since
> >>>> initial desired (signalled) value, as if the desired bandwidth
had
> >>>> and allocation and unicast negotiation.  Also note I'm assume
b=AS,

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 13:39:16 +0200

Of course.
Stephan

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 09:28:34 -0500

>TMMBR is a request or command to the sender not to send higher rate than

My point was that as worded, even if technically correct, people are likely
to mis-interpret the wording as a hard command because of the use of the
term "upper limit".  (I'd argue it's not technically correct even.)  We
should try to align our wording with the other RFCs to avoid confusion.
(This is similar to my objections to the term "session limit", which
implies a) a hard limit, which it is not, and b) that it's a bidirectional
shared limit, which it is not.)

>parameter for H.264 and H.263

Yes.  As mentioned by Stephan, the level limit is much more of a hard
limit, but I don't think we should reference that here.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 10:54:47 -0500

Stephan Wenger <[email-masked]> writes:
>Hi Randell, folks,
>
>in response to this thread, I have added a new section 3.5.4.1.  (right
>after the intro to TMMBR and TMMBN).  Do that level of detail  sound about
>right?
>Stephan
>
>> preferences for receiving bandwidth.  Therefore, a simple algorithm  is
>> specified in section 4.2.2.1to identify the most restrictive  TMMBR
                               ^ add a space
>> request.  The gist of that algorithm is explained informally  below.
>>
>> At any given time, a media receiver can send a TMMBR with a  bandwidth
>> limit that is lower than the current limit.  Once the  media sender has

                 ^^^^^ see below

>> sent the TMMBN message, the receiver indicated in  that message becomes
>> the ``owner’’ of the limitation.  Most likely,  the owner is the
>> original sender of the TMMBR -- for the handling  of corner-cases
>> (i.e. concurrent TMMBRs from different receivers,  lost TMMBRs and so on)
>> please see the formal specification.   ``Owner’’ and bandwidth
>> limit are known session wide, as both TMMBR  and TMMBN are multicasted.
>>
>> need to take into account TMMBR messages sent by anyone else  (although
>> that may well be a desirable optimization).  If the  ``owner’’ sets
>> the new session limit that is too high for someone  else’s liking,
>> other media receivers can react to the situation by  emmmitting their own
                                                         ^^^ spelling
>> TMMBR message (and, in the process, become  ``owner’’).

Doesn't the sender have to maintain the list of TMMBRs for everyone (so it
can assign a new "owner" if the current owner goes away)?  If so, wouldn't
it be nice if a UA could request a limit that's higher than the current
limit?   Then when the owner raises the limit, you don't have a flurry of
"wait, I want it lower" TMMBRs from all the other participants.  Instead,
you'd get the sender assigning the new bitrate to the new owner, and quite
likely no other traffic.  Downside: UAs send TMMBRs when their bandwidth
changes, even if they don't "own" it.  Upside: you avoid a possible burst
of TMMBRs when the owner raises it (or goes away) and associated
congestion.  BTW, I forget - can TMMBN specify there's no owner?  (I.e.
owner went away, and no other current receiver has ever sent a TMMBR.)

>> Obviously, when there is only one media receiver, this receiver  becomes
>> ``owner’’ once it receives the first TMMBN in response to  its own
>> TMMBR, and stays ``owner’’ for the rest of the session.
>> media receiver, the above algorithm is not required.  Media  receivers
>> can send TMMBR messages with bandwidth limits both higher  and lower than
>> the previously notified limit at any time (subject  to AVPF’s RTCP RR
>> send timing rules).

Is that last sentence talking to 'owners', receivers in unicast cases, or
receivers in general? (If in general, it conflicts with the discussion
above, and it probably shouldn't be at the end of the unicast paragraph.)

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 11:36:17 -0500

Stephan Wenger <[email-masked]> writes:
>> Doesn't the sender have to maintain the list of TMMBRs for everyone (so
>> it can assign a new "owner" if the current owner goes away)?
>
>That's not how the algorithm works.  Considering that multicast  groups can
>be quite large, we chose to avoid a mechanism that would  require keeping
>the state of potentially thousands or even millions  of TMMBR requests
>(however theoretical that use case may be,  today).   This motivation is
>also spelled out somewhere in the  section 4 discussion of TMMBR.

Sorry, couldn't remember that far back.  :-)

>>>> becomes ``owner’’ once it receives the first TMMBN in response
>>>> to its own TMMBR, and stays ``owner’’ for the rest of the
>>>> session.  Therefore, when it is known that there will always be only a
>>>> single media receiver, the above algorithm is not required.  Media
>>>> and lower than the previously notified limit at any time (subject to
>>>> AVPF’s RTCP RR send timing rules).
>>
>I have avoided the tern "unicast" (or multicast) in this paragraph,  and
>talk explicitly about a single media receiver only.  So yes, this  is
>point-to-point, and perhaps I should have referenced the point-to-
>point case in the Topologies draft.  It's the use case you are  interested
>in.  But it's not necessarily unicast, at least not when  you think in the
>IP unicast vs. IP multicast dimension.  If you start  a multicast session
>(i.e. you sent to an IP multicast address), and  only one receiver has
>joined (i.e. sent IGMP requests to his router),  this receiver becomes the
>owner and stays the owner till the end of  the session...

Ok, so maybe change the last sentence to start with "Owners" instead of
"Media receivers" (or some such).

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 18:47:52 +0200

> "Media receivers" (or some such).

I'll think of something.  Stay tuned for the next version of the  
draft.  Issue closed (I hope), pending next draft's review.

> from abroad."

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 18:16:54 +0200

Inline.
Stephan

>>> specified in section 4.2.2.1to identify the most restrictive  TMMBR

ok

>>> bandwidth
>>> (although

ok

> can assign a new "owner" if the current owner goes away)?

That's not how the algorithm works.  Considering that multicast  
groups can be quite large, we chose to avoid a mechanism that would  
require keeping the state of potentially thousands or even millions  
of TMMBR requests (however theoretical that use case may be,  
today).   This motivation is also spelled out somewhere in the  
section 4 discussion of TMMBR.

> If so, wouldn't
> limit?

It's not.

>   Then when the owner raises the limit, you don't have a flurry of
> likely no other traffic.

Yes, that would be true.  But it's not our design choice.  Btw: don't  
worry about the "flurry".  AVPF's timing rules take care of that.

> Downside: UAs send TMMBRs when their bandwidth
> congestion.

Again, this is not our design choice.

> BTW, I forget - can TMMBN specify there's no owner?  (I.e.

As you yourself has made us aware of :-), yes, TMMBN contains the  
SSRC of the owner, so everyone knows who the owner is.

>>> becomes
>>> receivers

I have avoided the tern "unicast" (or multicast) in this paragraph,  
and talk explicitly about a single media receiver only.  So yes, this  
is point-to-point, and perhaps I should have referenced the point-to- 
point case in the Topologies draft.  It's the use case you are  
interested in.  But it's not necessarily unicast, at least not when  
you think in the IP unicast vs. IP multicast dimension.  If you start  
a multicast session (i.e. you sent to an IP multicast address), and  
only one receiver has joined (i.e. sent IGMP requests to his router),  
this receiver becomes the owner and stays the owner till the end of  
the session...

Stephan

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jan 2007 15:36:01 +0100

> issue.  RFC 3550 assumes the application understands what IP/UDP/RTP header

Yes, at least my intention was that TMMBR applies to all RTP related 
packets sent from the indicated SSRC. RTCP traffic is excluded as that 
comes from another bandwidth pool. And the bitrate consumed is 
calculated as including RTP/UDP/IP.

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]
----------------------------------------------------------------------