Subject: [MMUSIC] Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 13 Mar 2007 11:06:36 -0700

MMUSIC folks,

Please use this thread to post any comments on
draft-hdesinen-mmusic-oa-send-bw-attr-02.txt

Thanks,

Hari

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Mar 2007 15:39:33 +0100

Hi,

Just by glancing on the draft I think this has completely misunderstood 
the bug with RFC 3890 and offer/answer. TIAS works fine for a sender to 
declare its intended usage of bandwidth, even over translator that 
changes that overhead. This as it consist of the RTP payload rate plus a 
maximum packet rate. That allows a receiver to calculate how much 
bit-rate will be consumed in worstcase when the packets arrive to the 
receiver, even if there been a IPv4->IPv6 translation by taking maxprate 
* actual packet overhead + TIAS.

The issue with TIAS in offer and answer is that you have no way of 
declaring your available receiver bandwidth combined with the expected 
packet header overhead. You can use AS which actually works fine as long 
as there are no overhead changes in the path. However in an environment 
where translation or tunneling will occur there will be problems with 
over utilization unless the media sender is made aware of the restrictions.

In addition there is a text bug that makes people believe that it 
applies to the receiver direction. But that is not true and simply a 
misstatement which I am responsible for. I didn't understand 
offer/answer well enough at this time. Nor did anyone else apparently.

Thus if one likes to fix the issues with TIAS and offer/answer then two 
things are needed. Update the RFC 3890 offer/answer section to make it a 
send direction only attribute. The other is to define a new reception 
bit-rate value that combines with a packet overhead attribute to allow 
media senders to know how its selection of packet rate will affect the 
bit-rate consumption.

Cheers

Magnus Westerlund

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 16 Mar 2007 09:24:44 -0700

Magnus,

Thanks for the comments. 

In the initial version, I captured the current understanding of (TIAS
,maxprate) based on RFC3890.

Based on the current RFCs, majority of the community interprets TIAS as
receive only direction attribute. Instead of updating RFC3890 to modify
TIAS as a send direction only attribute, it is better to use a new
attribute 'MSR' proposed in this draft. This would also avoid any
backward compatibility/inter-op issues that can arise with current
implementations which (correctly) interpret TIAS as receive direction
only attribute in offer/answer.

Another approach is to add directionality to TIAS. By default, TIAS is
receive only (not much useful) and "TIAS/sendonly" will be send only
direction. "maxprate/send" will be packet rate in send direction.

What you are proposing is the following
Send direction attributes: RTP Payload rate and maxpacket rate
Receive direction attributes: AS (or a new one), packet overhead

In this draft I am proposing that 'MSR' be used for signaling RTP
payload rate in 'send' direction. IMO, it is not a clean approach to
redefine TIAS to be a 'send' direction attribute.

I am OK with signaling packet rate in send direction. But we need to
consider whether to reuse maxprate for this or add directionality to
maxprate (maxprate/send) to avoid any inter-op issues with current
implementations.

Comments?

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, March 16, 2007 7:40 AM
> To: Desineni, Harikishan
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Comments on
draft-hdesinen-mmusic-oa-send-bw-attr-
> 02.txt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Mar 2007 17:44:28 +0100

> only attribute in offer/answer.

Well, I wonder how there can be backwards compatibility issues with 
something that clearly doesn't work if you actually try to use it. There 
might be implementations but I can't really understand how they could 
work. Do you know of implementations?

> Receive direction attributes: AS (or a new one), packet overhead

Okay, here I think the more important question is, are we expecting to 
be able to specify a value on another level than IP? If not I think AS 
works fine.

> redefine TIAS to be a 'send' direction attribute.

We disagree on this. TIAS was specified as a send direction attribute. I 
made an error in the offer/answer usage because I didn't consider the 
implications. And no one picked up on it.

As I can see it in regards to RFC 3890 we have two alternatives:

1. Fix the offer/answer section to correctly define it to apply in the 
sending direction.

2. Obsolete usage of TIAS in Offer/Answer exchanges and only use it for 
declarative usage, like in RTSP.

If there are implementations i any numbers that interpret TIAS as a 
receiver direction attribute then I agree alternative 2 will be best. 
However I would like to have some positive acknowledgments of this 
first. This was after all revealed in the attempt to apply TIAS to 
offer/answer in the 3GPP MTSI standardization work. Resulting in that 
TIAS was only included in the draft spec for a while. I don't know if 
some other umbrella standard has included TIAS combined with offer/answer.

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Sat, 17 Mar 2007 00:25:42 -0700

I copied a post (from AVT list) from Roni which states that TIAS was
actually used in his implementation. I am not sure if it is an
implementation in offer/answer model.

[CCed AVT as TIAS was also recently discussed on AVT list]

"
-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 7:35 AM
To: Randell Jesup
Cc: Stephan Wenger; [email-masked]
Subject: RE: [AVT] CCM draft review -- should "bandwidth" include
theheaderoverhead

Randell,
RFC 4890 recommends sending both TIAS and AS for backward compatibility
with systems that do not support TIAS. This RFC gives a good explanation
why to use TIAS. This is what we do in our implementation.
"

> Sent: Friday, March 16, 2007 9:44 AM
> To: Desineni, Harikishan
> Cc: [email-masked]