Subject: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-05.txt

From: [email-masked]
Date: Tue, 25 Oct 2005 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Profile for TCP Friendly Rate Control
	Author(s)	: L. Gharai
	Filename	: draft-ietf-avt-tfrc-profile-05.txt
	Pages		: 14
	Date		: 2005-10-25
	
This memo specifies a profile called "RTP/AVPCC" for the use of the
   real-time transport protocol (RTP) and its associated control
   protocol, RTCP, with the TCP Friendly Rate Control (TFRC).  TFRC is
   an equation based congestion control scheme for unicast flows
   operating in a best effort Internet environment.  This profile
   provides RTP flows with the mechanism to use congestion control in
   best effort IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-tfrc-profile-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-tfrc-profile-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: 25 Oct 2005 21:11:59 -0400

>   protocol, RTCP, with the TCP Friendly Rate Control (TFRC).  TFRC is

        Is it just me, or are we facing an explosion of pain over the
number of profiles being adopted?  Every time we create a new profile, we
need to create N more because most of these options are orthogonal.

        Will we now need AVPCCF, SAVPCC and SAVPCCF to be defined???  Not
to mention other possibilities...  And this will now mean that to initiate
a call will require navigating the waters of 8 possible semi-compatible
profiles....  And we don't have a way to properly and quickly handle this -
let alone in a single UDP packet (yes, I know TCP/TLS is preferred - but
it's also not widely deployed in a lot of commercial networks), or let
alone in a reliably compatible fashion.

        ARGH.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Tue, 25 Oct 2005 19:03:14 -0700 (PDT)

> need to create N more because most of these options are orthogonal.

That would be true if all of the combinations make sense.  Most of
them don't.  Some are merely not needed, and some would not work.  The
requirement to create a separate payload for each combination forces
some thought to be applied to those questions.

Personally, I have my doubts that a tfrc profile is worthwhile, but
that is another story.

>         Will we now need AVPCCF, SAVPCC and SAVPCCF to be defined???
>  Not to mention other possibilities...

No.  For example, I don't think AVPCCF would work.  Plus, they have
rather different domains of applicability.

In addition, I would favor developing any new profiles from a base of
SAVP rather than AVP.  Security is supposed to be built in now, right?

> And this will now mean that to initiate

No, you really don't want to use all of those combinations, so you
should not advertise them.  If the protocol conveyed all the profiles
independently so that any combination was possible, then you'd have to
implement all the combinations.  This way you don't.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Oct 2005 10:05:13 +0200

Hi,

See below.

> rather different domains of applicability.

I don't know what you demands from AVPCCF, but I think there are some 
reasonable ways of taking parts of AVPF into AVPCC. I think one needs to 
allow the usage of all AVPF feedback messages within AVPCC. There are a 
number of feedback messages that will be useful within the timing of 
RTCP that TFRC requires. And one has to realize that AVPCC will have 
quite rapid due to the requirement of a feedback message per RTT or sent 
packet. Thus the timing rules are not required to fulfill AVPF.

> SAVP rather than AVP.  Security is supposed to be built in now, right?

Is what Colin has argued for before. So far no agreement on this has 
been reached. I think the largest issue is not the implementation of 
SRTP within the profile but that all AVPCC requires a key management to 
be in place.

> implement all the combinations.  This way you don't.

I agree that not all profiles will be useful in a specific application 
and therefore are not interest to announce. Even when you come to the 
combinations with lower layer protocols will it be obvious. A specific 
application will need to determine what transport protocol that will be 
possible to use. In general I think 2 or 3 profiles is more than 
sufficient in the specific application that needs to be announced.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Randell Jesup <[email-masked]>
Date: 26 Oct 2005 19:06:58 -0400

Magnus Westerlund <[email-masked]> writes:
>number of feedback messages that will be useful within the timing of RTCP
>that TFRC requires. And one has to realize that AVPCC will have quite rapid
>due to the requirement of a feedback message per RTT or sent packet. Thus
>the timing rules are not required to fulfill AVPF.

        Certainly in most/all cases AVPCC will involve more frequent RTCP
traffic than AVPF would, so allowing the AVPF messages to be part of AVPCC
would generally work, if we allow for it.  I suggest we do.

>I agree that not all profiles will be useful in a specific application and
>therefore are not interest to announce. Even when you come to the
>possible to use. In general I think 2 or 3 profiles is more than sufficient
>in the specific application that needs to be announced.

        The problem really is that SDP is awkwardly defined for this - it
assumes that profile is more or less a given (accept or reject), and
negotiates agreement on the lower-level details (payloads,
rtpmap/fmtp/etc).  a= negotiation allows more nuanced control of things
like packetization periods, etc.

        Given the non-existant agreement on how to handle grouping and
alternative media streams (such as for different profiles), you have to
offer a number of profiles and let the other side pick, at the cost of a
lot of extra SDP lines basically duplicating all the payload data.

        Partly it's also been our choice, given the current regime - we
could have instead defined (or define) some of these things not as
profiles, but as negotiated a= parameters.  For example: if an offer were
to have m=... RTP/AVP and a=security:srtp instead of m=... RTP/SAVP, then
the responder could accept it (include a=security or reject/not understand
it (remove the a=)).  Ditto for AVPF.  Then we wouldn't need to offer 4
variant profiles as separate media streams.

        Perhaps (ok, probably) the defining thing making these want to be
(or have to be) profiles has been that the data can't be properly decoded
without knowing the answer, and the answer may be delayed behind the media
per normal SIP spec.  (Some UAs wait for an ACK to send media for various
reasons, which would avoid this particular reason for using profiles.)
Thus incoming port number becomes a psuedo-answer - it tells us which
profile was accepted (without any of the other information allowing return
media or RTCP).

        Even so, there were ways around this without requiring different
ports and not waiting for ACK: the security status could be tied to payload
value (and so implicitly convey the security response).  Something like
a=security:srtp 0 8 32 99 (for payloads that are SRTP).  This does have
some of the same sort of problem in that you have to add more lines (to
define secure and insecure payloads), etc.  

        BTW, having it as an a= parameter doesn't really decrease
security; the SIP traffic still should be authenticated.  This makes it
possible to attempt a bid-down if not authenticated, but the originator
still is in control - if the call was bid-down, the originator can (on the
OK) end the call if it wants to force security (and warn that a bid-down
was attempted).  Obviously the recipient was willing to accept a
no-security call already.

        All of this is (to a degree) neither here nor there - it's
irrelevant given SDP as it stands and the way profiles and profile
negotiation are done.  But it does mean we HAVE to solve the issues of
grouping, how the explosion of profiles affects things like ICE (*how* many
ports do you need to pry open before you can even send an invite???), etc.
These things have a serious negative impact on complexity, call setup
time(!), ability to fork calls, network overheads, and ability to use UDP
at all for the SIP traffic.  Moving to TCP/TLS can be done (with pain and
overhead) - but running a mixed network of UAs that support TCP and don't
is rather a nightmare, and I imagine requires a UA generating these
potentially huge SDPs to know how to dumb them down when the UA endpoint
can't receive the message due to UDP MTU (since we removed sending
fragmentation).  And what happens when a call forks to a TCP "fancy" client
that supports a lot of profiles, and to a UDP "dumb" client?

---

From: Ladan Gharai <[email-masked]>
Date: Wed, 26 Oct 2005 21:28:39 -0400

Hello Randell:

Please see inline.

>         Will we now need AVPCCF, SAVPCC and SAVPCCF to be  

This is a good question and it is also an issue for the profiles  
themselves - should the new profile address each possible combination  
(currently AVPCC does not) ? should it only address ones that make  
sense? and what happens when  future profiles are defined? would it  
be useful if the working group came up with general guidelines  
regarding profile combinations?

Specifically regarding AVPCC and AVPF, my take is that AVPCC can  
benefit from using the additional packets defined by AVPF. Much of  
AVPF's timing complexity is to avoiding feedback implosion in   
multiparty scenarios, however AVPCC cannot be used in a multiparty  
session, as TFRC is basically point to point. Therefore an AVPCCF  
profile, would allow the AVPCC profile to use the additional feedback  
packets defined in AVPF.

The combination of AVPCC and SAVP, also makes sense and would be  
useful but as Magnus points it mainly requires  key management.