Subject: RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 15 Jul 2001 21:21:55 -0400

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Sunday, July 15, 2001 7:18 PM
> To: Pete Cordell
> Cc: 'Christian Huitema'; Jonathan Rosenberg; [email-masked]
> Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> 
> I can think of one pretty unfortunate consequence
> of RTCP being on the same port. In some QoS
> reservation scenarios with certain popular coders,
> TDM-like slots can be allocated to give
> preferential treatment to the RTP stream,

TDM-like slots?? I thought we were working on IP protocols in IETF...

> typically allocated to the ceil() of the possible
> coders. If you put RTCP on the same port, you
> clearly wouldn't want to allocate the TDM-like
> slots as big as RTCP can be, so you'd have to
> figure out how to split RTCP out and send it some
> other way, or whatever.

Well, RTCP adds 5% of the bandwidth. Yes, it makes it more bursty, but not
by much. Any QoS mechanism already needs to handle bursty data (certainly
RSVP does), so I don't understand the problem.

 In other words, it gets
> pretty messy in a hurry. Leaving RTCP on a
> different port avoids all of that bother since
> it's a different u-flow (and can be treated as
> non-EF traffic too).

With EF, I also don't see an issue, since presumably the edge routers are
running a leaky bucket to mark packets.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 16 Jul 2001 13:38:41 -0500

The underlying QoS mechanisms for DOCSYS cable modems and for 3G wireless
(at least the GSM-derived stuff) are inherently TDM based. Essentially,
time-division is used to establish an effectively isochronous flow for the
voice path. This imposes the ceiling behavior MAT referred to. Spikes above
the reserved ceiling tend to cause something else to get clipped or slipped.
If the ceiling is defined at the average rate of RTP plus RTCP. we can get
through without clipping anything, but at a cost of creating single-window
jitter events at an interval defined by the the ratio of RTCP/RTP packets.

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "'Michael Thomas'" <[email-masked]>; "Pete Cordell"
<[email-masked]>
Cc: "'Christian Huitema'" <[email-masked]>; "Jonathan
Rosenberg" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Sunday, July 15, 2001 8:21 PM
Subject: RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 16 Jul 2001 20:32:34 -0700

Am I the only person here who's baffled that this idea (allowing RTP and 
RTCP to use the same port) is being taken seriously at all?  Not only would 
this would break most - if not all - existing RTP/RTCP implementations, but 
multiplexing control and data information at this level is generally 
considered bad design.

Please remind me again - what problem would this solve?  If, for whatever 
reason, the current RTP/RTCP port pairing (RTP on port 2n; RTCP on port 
2n+1) is considered too restrictive, then maybe we could consider relaxing 
*that* restriction, while still requiring RTP and RTCP to use separate ports?

         Ross.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 17 Jul 2001 07:39:24 -0400

On Mon, 16 Jul 2001 20:32:34 -0700
> multiplexing control and data information at this level

IMHO this is a bad idea. It will break things, and it
probably won't really fix the problem. Besides, it's hard
enough getting some vendors even to _implement_ RTCP.

It would be useful to allow "bundled" RTP groups to share
the same RTCP channel, though. If you have m RTP groups
associated with the same application, why not allow for RTP
on ports 2n, 2n+2, ..., 2n + m, and one RTCP channel on port 
2n + m + 1, so that only one set of control messages are
needed; the RR for all the groups can be combined together
as well.

Regards
Marshall Eubanks
  
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www.ietf.org/mailman/listinfo/avt

---

From: "Leonid Rosenboim" <[email-masked]>
Date: Wed, 18 Jul 2001 10:59:06 +0200

First, it has been discussed that NATs are one good reason for this change.
I only want to add that when IPv4/IPv6 interoperability is considered, some
interop scenarios have requirements similar to today's NAT. One last item I
wanted to add is that it is not far away that Internet CPE devices (e.g.
xDSL or Cable modems) would have a simple form of firewall embedded in them.
Since these security mechanisms are very simple, they also require for
authorizable traffic to be bidirectional, and initiated from within. Again,
somewhat NAT-like behavour.

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 18 Jul 2001 09:50:56 +0100

>>  *that* restriction, while still requiring RTP and RTCP to use separate
To which I add:
Hi Folks,
   I am also a little puzzled. RTCP does not seem to have a *minimum* bandwidth
so why have this at all? Simply don't send RTCP and either ignore any incoming
RTCP or let the NAT discard any packets.

There are some obscure scenarios in which packet traffic is actually carried
on connection-oriented bearers, and each new packet flow *may* need a heavy
weight setup procedure. In this case one can simply not deal with RTCP (for
very simple "two party" cases in which there's no absolute need for it).
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jul 2001 03:11:51 -0700 (PDT)

> somewhat NAT-like behavour.

   Uh, how do you initiate traffic from within when the
   traffic is not initiated from within? Like, oh say, a
   incoming call?

   There's some serious tail-wagging-dog going on here.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jul 2001 03:23:16 -0700 (PDT)

Lawrence Conroy writes:
 > weight setup procedure. 

   I guess that depends on your description of "obscure". 
   Dean rightly surmised I was thinking about the DOCSIS cable
   MAC/PHY and the ability to use unsolicited grants for RTP
   traffic. DOCSIS is pretty widely deployed these days, not
   to mention an ITU standard. Nor are TDM-like slotting 
   arrangements likely to vanish on certain kinds of media
   any time soon. The sin of the PSTN was to insist that
   there was exactly one way to build a shared media and that
   was with 64k TDM slots. That's not the same thing as saying
   that TDM is inherently bad under all circumstances.

 > In this case one can simply not deal with RTCP (for

   Sure there is; the same reasons you'd want to use RTCP
   in other cases. If nothing else, dead peer detection.

	    MIke

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 18 Jul 2001 11:58:19 +0100

>    I guess that depends on your description of "obscure".

I can think of other scenarios in Wireless/Cellular networks (and they're 3GPP
standards, so PacketCable/ITU isn't alone here :).
I don't think they're obscure either, but I hope they don't drive the overall
architecture for RTP/RTCP and break existing RTP/RTCP implementations.

>    in other cases. If nothing else, dead peer detection.

Fine; if you don't have a heavy weight/explicit connection scheme so 
you don't know
about transport or far end liveness, then you need it, so you have to 
take the pain.
I'm suggesting that, if you know when the link goes down from the 
"lower levels"
then you don't *always* need this. No big deal.

regards,
    Lawrence

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Jul 2001 08:30:18 -0400

> very simple "two party" cases in which there's no absolute need for it).

Lawrence,

given the discussion and conclusion we've had on this and related lists
in the last few weeks, I find your last statement, in its certainty,
more than surprising. May I suggest that you go back and read those
discussions before you state that there's no need for RTCP for unicast?

Thank you.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jul 2001 06:33:19 -0700 (PDT)

> architecture for RTP/RTCP and break existing RTP/RTCP implementations.

   I think my concern is exactly the opposite: that tweaks
   and changes to RTP do not break MAC/PHY's that were 
   designed with RTP in mind.

 > then you don't *always* need this. No big deal.

   Er, what if the network is partitioned somewhere in
   the middle and hence directly undetectable? Also:
   blowing away connections because a local interface
   flapped is almost always a bad idea. In reality,
   the local interface's long term death is about as unknowable 
   as an unobservable middle router's interface, unless it
   happens to have a "china syndrome" register or
   something :-)

	      Mike