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, 18 Jul 2007 18:49:32 -0700

Here is the draft which is an outcome of the discussions on
draft-hdesinen-mmusic-oa-send-bw-attr-02.txt. 

http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-bw-attr-00.
txt

I posted a -00 version of the new draft before 9th July but it did not
appear on IETF pages so far. Please read the draft at the above link
until it shows up on IETF web server. I'll start a separate thread to
collect comments on the new draft.

Thanks,
Hari

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2007 9:38 AM
> To: Desineni, Harikishan
> Cc: [email-masked]
> Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was
> RE:[MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt
> 
> 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.
> 
> > -----Original Message-----
> > From: Desineni, Harikishan [mailto:[email-masked]]
> > Sent: Friday, May 04, 2007 9:34 AM
> > To: Geir Arne Sandbakken; Even, Roni; [email-masked]
> > Cc: Magnus Westerlund; 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
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Geir Arne Sandbakken [mailto:[email-masked]]
> > > Sent: Thursday, May 03, 2007 7:05 AM
> > > To: Even, Roni; Desineni, Harikishan; [email-masked]
> > > Cc: Magnus Westerlund; 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
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: Even, Roni [mailto:[email-masked]]
> > > > Sent: 03 May 2007 08:03
> > > > To: Desineni, Harikishan; Geir Arne Sandbakken; [email-masked]
> > > > Cc: Magnus Westerlund; 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
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > From: Desineni, Harikishan [mailto:[email-masked]]
> > > > > Sent: Monday, April 30, 2007 2:13 PM
> > > > > To: Geir Arne Sandbakken; [email-masked]
> > > > > Cc: Magnus Westerlund; Even, Roni; 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