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

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

> -----Original Message-----
> From: Desineni, Harikishan [mailto:hdesinen <at> qualcomm.com]
> Sent: Wednesday, May 02, 2007 10:31 PM
> To: Desineni, Harikishan; Geir Arne Sandbakken; mmusic <at> ietf.org
> 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
> 
> 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:hdesinen <at> qualcomm.com]
> > Sent: Monday, April 30, 2007 4:13 AM
> > To: Geir Arne Sandbakken; mmusic <at> ietf.org
> > Cc: Magnus Westerlund; roni.even <at> polycom.co.il; 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:geir.sandbakken <at> tandberg.com]
> > > Sent: Wednesday, April 25, 2007 1:31 AM
> > > To: Desineni, Harikishan; mmusic <at> ietf.org
> > > Cc: Magnus Westerlund; roni.even <at> polycom.co.il; 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:hdesinen <at> qualcomm.com]
> > > > Sent: 17 April 2007 20:40
> > > > To: mmusic <at> ietf.org
> > > > Cc: Magnus Westerlund; roni.even <at> polycom.co.il; 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:hdesinen <at> qualcomm.com]
> > > > > Sent: Saturday, March 17, 2007 12:26 AM
> > > > > To: Magnus Westerlund; roni.even <at> polycom.co.il
> > > > > Cc: Mahendran, AC; Dondeti, Lakshminath; mmusic <at> ietf.org;
> > > avt <at> ietf.org
> > > > > 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:roni.even <at> polycom.co.il]
> > > > > Sent: Monday, January 08, 2007 7:35 AM
> > > > > To: Randell Jesup
> > > > > Cc: Stephan Wenger; avt <at> ietf.org
> > > > > 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:magnus.westerlund <at> ericsson.com]
> > > > > > Sent: Friday, March 16, 2007 9:44 AM
> > > > > > To: Desineni, Harikishan
> > > > > > Cc: mmusic <at> ietf.org
> > > > > > 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:
> > > magnus.westerlund <at> ericsson.com
> > > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > mmusic mailing list
> > > > > mmusic <at> ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/mmusic
> > > >
> > > > _______________________________________________
> > > > mmusic mailing list
> > > > mmusic <at> ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic