Subject: 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: Tue, 17 Apr 2007 11:40:04 -0700

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

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 25 Apr 2007 10:31:15 +0200

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

> 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
> 
> came out while discussing
draft-hdesinen-mmusic-oa-send-bw-attr-02.txt.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 30 Apr 2007 04:13:14 -0700

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

> From: Geir Arne Sandbakken [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2007 1:31 AM
> To: Desineni, Harikishan; [email-masked]
> Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE:
> > 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
> > > > If there are implementations i any numbers that interpret TIAS
as
> a