Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE:[MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 2 May 2007 12:31:17 -0700

Given that there are already implementations of TIAS it is clear that
changing the direction of TIAS is not the correct direction.

The "MSR" attribute defined in
draft-hdesinen-mmusic-oa-send-bw-attr-02.tx would still be useful to
signal bit-rate (RTP Payload) in 'send' direction. Based on the
discussions we had on this thread, the following would make sense to
address the problem completely. 

 1. Obsolete (TIAS, maxprate) for offer/answer and limit it to
declarative
 usage (Updates rfc3890)
 2. Propose MSPR (max send packet rate)
 3. Propose RB (receive bit-rate at layer X)
 4. Propose PO (packet overhead from layer X to the application layer)

Media Sender would attempt to satisfy the equation --> 
MSR+ (PO*MSPR) <= RB 

[
MSR - local send RTP payload bit-rate,
PO- remote packet overhead at layer X,
MSPR- local max packet send rate,
RB- remote last hop receive bit-rate at layer X
]

I prefer this to be captured in a new draft named "SDP attributes for
Offer/Answer Sessions" rather than having a draft for "MSR" attribute
alone.

Let me know if you have any comments.

Thanks,
Hari

> -----Original Message-----
> From: Desineni, Harikishan [mailto:[email-masked]]
> Sent: Monday, April 30, 2007 4:13 AM
> To: Geir Arne Sandbakken; [email-masked]
> Cc: Magnus Westerlund; [email-masked]; Colin Perkins
> Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was
> RE:[MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt
> 
> Geir,
> 
> Thanks for your feedback.
> 
> Can you elaborate on how exactly this attribute is used in the
> implementations known to you? I'd like to understand how closely or
> differently it is used from the way it is documented in rfc3890.
> 
> Thanks,
> Hari
> 
> > -----Original Message-----
> > From: Geir Arne Sandbakken [mailto:[email-masked]]
> > Sent: Wednesday, April 25, 2007 1:31 AM
> > To: Desineni, Harikishan; [email-masked]
> > Cc: Magnus Westerlund; [email-masked]; Colin Perkins
> > Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE:
> > [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt
> >
> > Harikishan,
> >
> > We have been using TIAS in the 'recv' direction for quite a while,
and
> I
> > know of multiple other implementations.  Think we have been
promoting
> > the usage in the last 3 SIPit's, and changing the direction will
lead
> to
> > serious interoperability issues.
> >
> > I do agree that a 'send' direction attribute is desirable as
> additional
> > bandwidth information, and I hope it can be done without breaking
> > existing implementations.
> >
> > Cheers,
> > Geir Arne
> >
> > > -----Original Message-----
> > > From: Desineni, Harikishan [mailto:[email-masked]]
> > > Sent: 17 April 2007 20:40
> > > To: [email-masked]
> > > Cc: Magnus Westerlund; [email-masked]; Colin Perkins
> > > Subject: Proposal to modify RFC3890 TIAS in offer/answer Was RE:
> > > [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt
> > >
> > > Some issues with the offer/answer usage of TIAS (defined in
RFC3890)
> > > came out while discussing
> > draft-hdesinen-mmusic-oa-send-bw-attr-02.txt.
> > >
> > > RFC3890 has incorrectly defined TIAS and maxprate as 'recv'
> direction
> > > attributes in offer/answer model. As 'recv' attributes, TIAS and
> > > maxprate do not solve the bandwidth negotiation problem. For
> > > offer/answer bw negotiation to work properly, the correct
direction
> in
> > > rfc3890 should have been 'send', probably with the help of few new
> > > 'recv' direction attributes (like PO - per packet overhead at
layer
> X,
> > > RB- receive BW at layer X) under discussion.
> > >
> > > A sender would choose (TIAS,maxprate) which satisfy the following
> > > formula
> > > TIAS + (maxprate * PO) <= RB (PO and RB are signaled by the
> receiver)
> > >
> > > One approach to handle this is changing the direction of
> > (TIAS,maxprate)
> > > to 'send' and prevent the incorrect ('recv') usage of
> (TIAS,maxprate)
> > in
> > > offer/answer model. While this appears to be the desired
direction,
> I
> > am
> > > interested to know the impact of such a change on (any) existing
> > > implementations of TIAS in offer/answer.
> > >
> > > Please comment if you are aware of any existing implementations of
> > TIAS
> > > in offer/answer and also describe how exactly TIAS was used in
that
> > > particular implementation.
> > >
> > > Thanks,
> > > Hari
> > >
> > >
> > > > -----Original Message-----
> > > > From: Desineni, Harikishan [mailto:[email-masked]]
> > > > Sent: Saturday, March 17, 2007 12:26 AM
> > > > To: Magnus Westerlund; [email-masked]
> > > > Cc: Mahendran, AC; Dondeti, Lakshminath; [email-masked];
> > [email-masked]
> > > > Subject: RE: [MMUSIC] Comments on
> > > draft-hdesinen-mmusic-oa-send-bw-attr-
> > > > 02.txt
> > > >
> > > > 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.
> > > > "
> > > >
> > > > > -----Original Message-----
> > > > > From: Magnus Westerlund
[mailto:[email-masked]]
> > > > > Sent: Friday, March 16, 2007 9:44 AM
> > > > > To: Desineni, Harikishan
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [MMUSIC] Comments on
> > > > draft-hdesinen-mmusic-oa-send-bw-attr-
> > > > > 02.txt
> > > > >
> > > > > Desineni, Harikishan skrev:
> > > > > >
> > > > > >
> > > > > > 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.
> > > > >
> > > > > 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?
> > > > >
> > > > > >
> > > > > > 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
> > > > >
> > > > > 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.
> > > > >
> > > > > >
> > > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > 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]
> > > > >
> > >
> ----------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > mmusic mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 3 May 2007 09:00:41 +0300

Harry,
According to Geir Arne and I the usage today of TIAS is as a receive
capability in the media line. As far as I understand declaratives means
on the send direction, so please clarify the usage for receive
capability.
Roni

> Sent: Wednesday, May 02, 2007 10:31 PM
> To: Desineni, Harikishan; Geir Arne Sandbakken; [email-masked]
> Cc: Magnus Westerlund; Even, Roni; Colin Perkins

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 3 May 2007 09:02:38 +0300

Hary,
TIAS is being used as a media level attribute indicating the maximum BW
that the receiver would like to get. It is not used in offer answer. The
semantic of the attribute (what is bw) is as specified in RFC 3890

Roni

> Sent: Monday, April 30, 2007 2:13 PM
and
promoting
lead
RFC3890)
direction
layer
direction,
that
include
RFC3890
a
avoid
they
default,
rate
signaling
apply
use
be
TIAS
in

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Thu, 3 May 2007 16:04:34 +0200

Hari,

We are using it just as Roni explains. Receiver bandwidth indication has
been very useful for us, and it makes it possible to do quick
adjustments at the sender side without any renegotiation.

Cheers,
Geir Arne

> Sent: 03 May 2007 08:03
> Cc: Magnus Westerlund; Colin Perkins

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 4 May 2007 08:34:13 -0700

Thanks for the responses.  I too think that the declarative usage of
TIAS as a receive bit-rate (RTP Payload) in offer/answer shall continue
to exist.

Thanks,
Hari

> Sent: Thursday, May 03, 2007 7:05 AM
> To: Even, Roni; Desineni, Harikishan; [email-masked]
RE:
> > > > > [MMUSIC]Comments on
draft-hdesinen-mmusic-oa-send-bw-attr-02.txt
> > > > > Please comment if you are aware of any existing
implementations
> > > > > > > be able to specify a value on another level than IP? If
not
> > > > > > > > I am OK with signaling packet rate in send direction.
But
> we

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 9 May 2007 10:37:52 -0600

Hari,

   It seems there are some issues as pointed out by your
draft-hdesinen-mmusic-oa-send-bw-attr-02, and the requirements in RFC
3890 & 3264.

Based on the txt on the b param in 3264, 
    |  "If the bandwidth attribute is present for a stream, 
    |   it indicates the desired bandwidth that the offerer
    |   would like to receive."
and the notes from folks who have implemented it and responded to the
list, I too agree that it is best to keep the current usage (TIAS as
declarative of what the agent is willing to receive).

An update to 3890 with a new TIAS value and clarifications about the
current ones seem appropriate. 

Does anyone disagree on this path forward?

Jean-Francois.

> Sent: Friday, May 04, 2007 9:34 AM
> To: Geir Arne Sandbakken; Even, Roni; [email-masked]
> > > TIAS is being used as a media level attribute indicating the
> maximum
> > BW
> > > that the receiver would like to get. It is not used in offer
> answer.
> > The
> > > > > > rfc3890 should have been 'send', probably with the help of
> few
> > new
> > > > > > > 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
> > > > > > > > > TIAS as a send direction only attribute, it is better
> to
> > use
> > > a
> > > > > new
> > > > > > > > something that clearly doesn't work if you actually try
> to
> > use
> > > > it.
> > > > > > > There
> > > > > > > > > receive only (not much useful) and "TIAS/sendonly"
> will
> be
> > > > send
> > > > > > only
> > > > > > > > If there are implementations i any numbers that
> interpret
> > TIAS
> > > > as
> > > > > a
> > > > > > > > However I would like to have some positive
> acknowledgments
> > of
> > > > this

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 9 May 2007 11:53:27 -0700

My current plan (based on the feedback received on this mailing list and
some offline discussions) is to write a new draft (updates rfc3890) with
title "SDP bandwidth attributes in offer/answer sessions". The new draft
will describe the new type of usage of TIAS and obsolete the combined
usage of (TIAS,maxprate) for offer/answer. No disagreement was expressed
for this change on this mailing list so far. At this time it would be
good to know if there are any disagreements on this part.

In addition, the new draft will propose several new SDP attributes
("MSR" for bit-rate in send direction, "RB" ...) for further review.

Thanks,
Hari

> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2007 9:38 AM
> To: Desineni, Harikishan
> Cc: [email-masked]
RE:
> > > We are using it just as Roni explains. Receiver bandwidth
indication
> > has
> > > > > implementations known to you? I'd like to understand how
closely
> > or
> > > > > > > Subject: Proposal to modify RFC3890 TIAS in offer/answer
Was
> > > > > > > attributes in offer/answer model. As 'recv' attributes,
TIAS
> > > > > > > in offer/answer and also describe how exactly TIAS was
used
> > > > > > > > > > backward compatibility/inter-op issues that can
arise
> > > > > > > > > Well, I wonder how there can be backwards
compatibility
> > > issues
> > > > > > > > > 2. Obsolete usage of TIAS in Offer/Answer exchanges
and
> > > > > > > > > receiver direction attribute then I agree alternative
2
> > > > > > > > > TIAS was only included in the draft spec for a while.
I
> > > don't
> > > > > know
> > > > > > > if
> > > > > > > > > some other umbrella standard has included TIAS
combined
> > > > > > > > > > maxprate (maxprate/send) to avoid any inter-op
issues
> > > > > > > > > IETF Transport Area Director & TSVWG Chair
--------------------------------------------------------------------
> > --
--------------------------------------------------------------------
> > --
--------------------------------------------------------------------
> > --

---

From: "Ashish Goyal" <[email-masked]>
Date: Wed, 9 May 2007 22:38:18 -0500

Hi Hari, 
	As long as the declarative usage of TIAS remains - I am fine. We
have been using it in a declarative mode in videoconferencing arena. I
would be interested in staying the loop for the proposed modifications
to rfc 3890 or of the usage of TIAS/maxprate.

Thanks, 
Ashish

-----Original Message-----
From: Desineni, Harikishan [mailto:[email-masked]] 
Sent: Thursday, May 10, 2007 12:23 AM
To: Jean-Francois Mule
Cc: [email-masked]
Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer
WasRE:[MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt

Thanks,
Hari

> > TIAS as a receive bit-rate (RTP Payload) in offer/answer shall 
> > continue to exist.
> >
> > Thanks,
> > Hari
> >
indication

closely
Was
TIAS
used
arise
compatibility
> > > > > > > > > > What you are proposing is the following Send 
> > > > > > > > > > direction attributes: RTP Payload rate and
> > maxpacket
> > > > rate
and
2
I
combined
issues