Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Nov 2006 09:07:41 +0000

On 1 Nov 2006, at 04:39, Philip Zimmermann wrote:
> We do up to 20 retries of the Hello packet, because we empirically  
> observe a high packet loss rate at the start of media stream, which  
> only lasts a second.  This is exactly the same period that we do  
> our entire ZRTP protocol.  We used to have a retry limit of 10, but  
> that was not enough.

So you try to overcome initial congestion by sending more data? I'm  
not surprised you see packet loss. Sending 20 copies of a packet to  
blast through congestion is completely unacceptable from a congestion  
control viewpoint (see discussion in RFC 2914). The data will have to  
be paced out somehow, instead.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 01 Nov 2006 10:36:48 +0100

Hi David,

David R Oran skrev:
> What am I missing?

In my view not much. It seems quite clear that some are trying to 
motivate breaking the architecture using minor issues that mostly 
depends on broken implementations.

I also would like to clarify that although I said there are potentials 
with AVPF, I think there are other ways, such as holding the normal RTP 
traffic and utilize some sizable percentage of that for completing the 
key-exchange. If one is worried about QoS then ensure that you do the 
RTP+RTCP muxing and they will belong to the same flow.

I think we should concentrate on having a creative discussion on how to 
best resolve this rather than simply blast at each other. Taking 
architecture, sound engineering and internet pragmatics into account.

As a comment on the congestion and re-try timer for ZRTP. You better fix 
this in some reasonable way, because you will not be able to publish 
this unless it gets fixed. You do need to consider both varying RTTs and 
the need to avoid causing significant congestion.

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: David R Oran <[email-masked]>
Date: Wed, 1 Nov 2006 07:44:38 -0500

On Oct 31, 2006, at 11:39 PM, Philip Zimmermann wrote:

> that was not enough.  So don't assume that this won't impact RTCP  
> bandwidth quotas.
>
So much for congestion-friendly behavior, huh?

>
> On Oct 31, 2006, at 12:58 PM, Colin Perkins wrote:
>
>> On 31 Oct 2006, at 20:19, Randell Jesup wrote:
>>> Colin Perkins <[email-masked]> writes:
>>>>> Except those middleboxes may well reject unknown packets on the  
>>>>> RTP  port.
>>>>> And in any case, we're putting bandaids on bandaids here - and  
>>>>> even  with
>>>>> this, there are serious bandwidth issues.
>>>>
>>>> We standardised the mechanism to signal to those middleboxes  
>>>> three  years
>>>> ago. Push on the vendors and operators to implement them and   
>>>> those kludges
>>>> go away. It's not like the "a=rtcp:" attribute is  difficult,  
>>>> compared to
>>>> some of the stuff that does get implemented...
>>>
>>> True.  But there are a zillion RFCs, and unless there's an  
>>> application/
>>> business requirement for one of them, many or even most of them  
>>> don't get
>>> implemented.  From their point of view, should they spend that time
>>> (including regression testing!!) on this, or should they put it  
>>> onto the
>>> Next Big Feature that everyone is clamoring for?  Plus, even if
>>> implemented, many vendors won't update a box unless they must.   
>>> They often
>>> run years-old software versions.
>>
>> NAT traversal and security aren't the Next Big Thing?
>>
>> ...
>>>>>> I'd prefer ZRTP to use RTCP packets ignoring the timing rules  
>>>>>> for the
>>>>>> initial negotiation, than for it to embed control information  
>>>>>> into RTP
>>>>>> media packets. Neither is ideal, but this seems the least bad
>>>>>> alternative architecturally, given that the community seems to  
>>>>>> have
>>>>>> decided to punt the keying problem onto this group, rather  
>>>>>> than fixing
>>>>>> the SIP layer.
>>>>>
>>>>> Ignoring the timing rules, or timing and bandwidth?
>>>>
>>>> The timing rules. I see no need to violate the bandwidth rules,  
>>>> on  average
>>>> (and there are no short-term guarantees with RTCP anyway, due   
>>>> to it's
>>>> statistical nature).
>>>
>>> There's less need to violate the timing rules (I think) with AVPF.
>>> However, the bandwidth rules still mean an up-to-10-second key  
>>> negotiation
>>> (ignoring packet losses).  That's simply unusable, and that sort  
>>> of issue
>>> is why they're doing something even uglier in the current draft  
>>> (header
>>> extensions).
>>
>> I don't see why you can't send the ZRTP exchange at *exactly* the  
>> same rate as in the current draft, while still using RTCP. You do  
>> the key exchange quickly, then delay your next RTCP packet to  
>> compensate. Overall bandwidth fraction the same as with standard  
>> RTCP, but violates the timing rules a little (in the same way AVPF  
>> does, but for several (two?) packets, rather than just for one  
>> packet).
>>
>>> What's your objection to something like:
>>>
>>> m=audio 4321 RTP/AVP 0 99
>>> a=rtpmap:99 ZRTP/8000
>>> a=rtpmap:0 PCMU/8000
>>
>> ZRTP keying negotiation packets aren't audio data.
>>
>> Colin
>>
> ----------------------------------------------
> Philip R Zimmermann        [email-masked]
> http://philzimmermann.com  tel +1 650 322-7223
> (spelled with 2 n's)       fax +1 650 322-7877
>
>
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 01 Nov 2006 08:49:05 -0600

David R Oran wrote:
>> only lasts a second.  This is exactly the same period that we do our 
>> entire ZRTP protocol.  We used to have a retry limit of 10, but that 
>> was not enough.  So don't assume that this won't impact RTCP 
>> bandwidth quotas.
>>
We are attempting to mimic the behavior of RTP itself - sending ZRTP 
messages every 50ms at the very start of a media session.  The reason 
for this is the commonly observed high packet loss for the first few 
packets at the start of a media session.  Just sending a single ZRTP 
message then waiting a couple of round trip times for a reply just 
doesn't work, and a protocol designed this way will fail in the real 
world test (i.e. running code).

We have not thought about bandwidth considerations when a low bit rate 
codec is in use, which still may send packets every 50ms but they will 
be much smaller.   We can refine this retransmission rate for some of 
these circumstances.

Thanks,
Alan
>>>>>>> alternative architecturally, given that the community seems to have
>>>>>>> decided to punt the keying problem onto this group, rather than 
>>>>>>> fixing
>>>>>>> the SIP layer.
>>>>>>
>>>>> (and there are no short-term guarantees with RTCP anyway, due  to 
>>>>> it's
>>>>> statistical nature).
>>>>
>>>> (ignoring packet losses).  That's simply unusable, and that sort of 
>>>> issue
>>> does, but for several (two?) packets, rather than just for one packet).
>>>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Nov 2006 15:17:25 +0000

On 1 Nov 2006, at 14:49, Alan Johnston wrote:
>>> We do up to 20 retries of the Hello packet, because we  
>>> empirically observe a high packet loss rate at the start of media  
>>> stream, which only lasts a second.  This is exactly the same  
>>> period that we do our entire ZRTP protocol.  We used to have a  
>>> retry limit of 10, but that was not enough.  So don't assume that  
>>> this won't impact RTCP bandwidth quotas.
>>>
> We are attempting to mimic the behavior of RTP itself - sending  
> ZRTP messages every 50ms at the very start of a media session.  The  
> reason for this is the commonly observed high packet loss for the  
> first few packets at the start of a media session.  Just sending a  
> single ZRTP message then waiting a couple of round trip times for a  
> reply just doesn't work, and a protocol designed this way will fail  
> in the real world test (i.e. running code).

There's a lot going on at the start of a call: signalling traffic,  
media data, ICE, ZRTP, etc. I agree that this may cause packet loss  
in some cases, due to congestion of the access links, but I'm  
unconvinced that the solution is to ignore that loss and keep  
retransmitting until some data gets through. That just makes the  
problem worse overall, as different parts of the system fight over  
the limited capacity.

We need to consider some form of slow-start and rate limiting for  
ZRTP, for ICE, and for the media traffic, to avoid congesting the  
links in the first place.

Colin

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Nov 2006 10:19:13 -0500

Magnus Westerlund <[email-masked]> writes:
>In my view not much. It seems quite clear that some are trying to motivate
>breaking the architecture using minor issues that mostly depends on broken
>implementations.

I have no wish to break the architecture; in fact, that's part of why I'm
trying to find workable ways around using header extensions.  I do worry
about producing a solution that will work in practice; I've seen WAY too
many hugely non-compliant implementations out there that are so entrenched
there's simply no way to deal with them other than to massively warp specs.
And you can't ignore them, because they're in almost every commercial
SIP<->PSTN gateway, for one random example.  (I'm speaking to a more
general example of the problem, not the specific problems with ZRTP
negotiation.)  The same sorts of problems are driving things like
best-effort key exchange.

I also do not see a ZRTP payload as a "breaking" of the architecture.  At
most, you can say that it bends things by the fact that it's not "audio".
In my mind, though, it's a much clearer, cleaner and less troublesome
solution.  No new profiles, no support for RTCP on RTP ports, no breaking
of timing rules, no worrying about interfering with normal RTCP near the
beginning of the call (by sucking up all the RTCP bandwidth and messing up
the average-size calculation for a while), signalled (and therefore
rejectable, saving bandwidth in cases where one side supports it and the
other doesn't), allows the application to decide whether to do fast
no-media key exchange, doesn't cause problems with QoS channels, etc.
That's a lot of "win" for the fact that it's not really "audio" data.

(For that matter, why did streams have to be tagged with "audio" or "video"
or "data"?  That's really more an artifact of the codecs involved; it seems
like "audio"/etc merely is a convenient hint and doesn't add any real
(useful) information or semantics - the payload types and associated
rtpmaps and fmtps and other a= parameters tell you what the stream and
packets "are".  But that's a tertiary issue.)

>I also would like to clarify that although I said there are potentials with
>AVPF, I think there are other ways, such as holding the normal RTP traffic
>and utilize some sizable percentage of that for completing the

RTP/RTCP mux (once agreed to, and once implemented by all the network
elements) would allow you to keep them in the same flow and QoS
reservation.  You'd still have the other issues about profiles, RTCP timing
rules and average size calculations, etc.

>architecture, sound engineering and internet pragmatics into account.

Agreed, absolutely.  I'll also admit that I tend to fall on the side of
implementabilty and robustness over architectural purity.

>this in some reasonable way, because you will not be able to publish this
>unless it gets fixed. You do need to consider both varying RTTs and the
>need to avoid causing significant congestion.

Definitely.  I hadn't looked at the retry-mechanisms in ZRTP; it sounds as
if they don't take into account any of the normal congestion-control
issues.

My initial off-the-cuff suggestion (for the current bump-in-wire ZRTP)
would be to use ZRTP packets in place of normal data packets, paced at the
normal stream data-packet rate.  This does require ZRTP to know (or
measure) the data-packet rate.  If you're suppressing normal data during
negotiation, this is fairly easy.  If not suppressing, then some hybrid
solution which uses a low-bandwidth 'hello' attached to data packets in a
hdr-ext-compliant way (occasionally) or replacing data packets
(occasionally), etc.

The main cases to worry about for handshake and congestion control are:

1) Initial loss -- Total loss of packets for a variable period after
   signalling completes.  Typically due to network security/mapping
   elements such as NATs, firewalls, and perhaps SBCs.
2) Congestion -- overuse of bandwidth available, causing random loss, most
   frequently in packets after the first one or few.  Note that in some
   cases and some codec types, startup-time congestion may be a fact of
   life that has to be adapted to.  See TFRC.
3) "random" (medium, path, cross-path congestion) loss.  Packet loss in
   802.11, short-period intermediate-hop/cross-path congestion loss.
4) Delayed completion of signalling (not really media-path loss) -- delayed
   or lost 200 OK's and ACKs.
Are there others to worry about here?

Initial loss pushes you to try to contact the other side until it gets
through (perhaps what's driving the current ZRTP implementation), but that
can directly conflict with #2, Congestion loss.  This is especially the
case in that neither side in current implementations has any idea if the
other side supports it (since there's no signalling side), or if it doesn't
respect the signalled bandwidth limits.  A signalling of ZRTP support can
simplify things here.

There are some reasonable ways to attack this I think, but I don't want to
jump too far ahead of the discussion, so I'll let them stew for a bit while
others respond.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Nov 2006 10:53:45 -0500

David R Oran <[email-masked]> writes:
>>> If (a), then the whole session bandwidth is actually available to   RTCP
>>> since the bandwidth restrictions on RTCP are intended to keep  the  total
>>> bandwidth of RTP+RTCP below the session bandwidth.
>>
>> That would be the case - except that QoS channels are typically tied to
>> ports, and so (for example) if you have a b=AS:100 on a stream on port
>> X, comcast/packetcable reserves around 100Kbps for X, and around 5Kbps
>> for port X+1 (or the a=rtcp port).  So even if you don't use port X, you
>> may not be able to send more than 5Kbps on X+1.  Similar problems may
>> crop up for other tight-bandwidth/QoS channels like 3G, 802.11e, etc.
>>
>Oh, come on. the dead fish are just piling up on the table. If 3G is
>policing per port, they got to be nuts.

I know for a fact that some (perhaps all) of the PacketCable SIP QoS
solutions do police per-port (flow).  I don't know what limits they put on
each port.  I know the limits on the RTP port are directly related to the
SDP b=AS/etc parameters in the case I saw.  It's possible that they
ignore RTCP and let that go best-effort.  This would be "good" in that
you wouldn't be limited, but "bad" in that you lose the advantage of the
QoS.  If they do reserve a channel, from what I know they would limit it.
Others will have to speak to 3G; on that I'm guessing, but they are far
more bandwidth-aware than other apps from what I've seen.

>If you can't get a best effort key exchange through on a random UDP  port,
>lots of things are going to break and zrtp won't be the only one.

It's not a random port though, it's a port where there's an agreement as to
the maximum bandwidth to be used, and where there's incentive to give those
packets priority (up to that bandwidth).

A random best-effort port would avoid the QoS/throttling issues - except
for the whole issue of opening another port through NATs/etc.  That is an
option I mentioned earlier (negotiate on another m=data stream).  That
would probably have a class of issues with support from network elements in
addition to the NAT issues, so I don't know how practical it is.  Also,
since it's now a separate stream from the data, the protocol has to have a
way to associate a given key with the correct m=whatever stream (and
individual streams might terminate in different devices, so this might be
an impractical idea).

>> In some cases it does, but you can't count on it,
>In the IP world, you can't count on anything in the sense you're raising
>objections.  I suppose one could say that these silly policers are doing
>DPI and stomping on the precious zrtp payload types too.

Sure, and someone can purposely block ZRTP, regardless of whether it's in
header extensions, RTCP or a separate payload.  There are ways to avoid
that, but then we're getting into variations of steganography, and that's
outside this conversation.  The idea here is to come up with something that
will work reasonably well in most practical cases, not to deal with every
single way something could cause problems.  But where we can solve a class
of problems without causing a equivalently-large class of problems to crop
up, that's well-worth considering.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Nov 2006 08:02:39 -0800

Alan,

I have long been curious:  can you describe the minimum lab configuration
that can duplicate the initial packet loss you're seeing?  I mean, is it two
phones on the same Ethernet hub, two phones on the Internet with NATs,
firewalls, and SBCs between them, or something in-between?

Being able to characterize this will be useful for ZRTP as well as for
DTLS-SRTP and MIKEYv2, as well as comedia (which uses TCP) and comedia with
TCP/TLS.

-d

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 6:49 AM
> To: David R Oran
> Cc: Philip Zimmermann; Randell Jesup; Colin Perkins; Dan 
> Wing; [email-masked]
> Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]
> 
> David R Oran wrote:
> >

---

From: Alan Johnston <[email-masked]>
Date: Wed, 01 Nov 2006 10:04:10 -0600

Colin Perkins wrote:
> media data, ICE, ZRTP, etc. I agree that this may cause packet loss in 
> some cases, due to congestion of the access links, but I'm unconvinced 
> that the solution is to ignore that loss and keep retransmitting until 
> some data gets through. That just makes the problem worse overall, as 
> different parts of the system fight over the limited capacity.
>
Here is the exact scenario.   The first x packets sent in the RTP flow 
path suffer congestion for the first y seconds of the media stream.  
After that, the congestion goes away completely.  We have all observed 
this in VoIP.  I remember when we first saw this at MCI.   We noticed 
that we had some clipping problems in SIP phone to SIP phone calls but 
almost never in SIP phone to Gateway calls.  What was the difference?  
Gateway calls involved early media.  When we observed this early media 
closely (ringing tone from the PSTN), we noticed the start of the early 
media was clipped, but no one cared.  I think it is just a function of 
the various routers and switches at the IP layer adjusting to a new 
regular packet flow starting up.  The packet loss goes away quickly as 
long as regular RTP packets are sent.  It can cause clipping problems 
for voice, but it is disaster for things like ICE and ZRTP.

So, implementing strict congestion control, slow-start or rate limiting 
during this transient condition will actually extend the transient 
period and make the situation worse.

Thanks,
Alan

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 1 Nov 2006 16:27:11 -0000

A question - In the early discussions on NAT traversal it was suggested life
would be easier if RTP and RTCP shared the same port.  Back then it was
pointed out that it was architecturally impure (the muxing should be done at
the port level - that's why RTP is the way it is!) and also the RTCP
bandwidth would have to be included in the QoS reservation for the RTP and
for some systems this would be problematic.

I'm just wondering what has changed now that it is proposed the RTCP should
be sent on the RTP port for ZRTP?  Aren't all the solutions proposed so far 
architecturally impure?

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Nov 2006 17:58:08 +0000

On 1 Nov 2006, at 16:27, Pete Cordell wrote:
> be sent on the RTP port for ZRTP?  Aren't all the solutions  
> proposed so far architecturally impure?

The community seems to have given up on fixing security parameter  
negotiation in SIP, and has punted it to the RTP layer. The least bad  
way of incorporating such negotiation at the RTP layer would seem to  
be to do it in RTCP, since that keeps control and data logically  
separate. The only way we seem to be able to get RTCP traffic to flow  
is by multiplexing it with RTP, due to the NAT traversal issues.

I don't like it, and I know it will break things, but the  
alternatives would all seem to be even less compatible with the RTP  
architecture.

Colin

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Nov 2006 17:29:16 -0500

>firewalls, and SBCs between them, or something in-between?

I'd be interested too; I haven't really seen this.  In some cases (slow
heavily loaded links) it makes sense, since until the existing TCP flows
adapt to the new CBR flow on the same link, all of them will see loss.
With larger-bandwidth (more flows) on the link, you should see little or
no loss for the new (CBR RTP) flow before the TCP flows adapt.  

I suspect the situations where you see this are:
1) shared DSL/cable or heavily shared T1ish or fractional-T1 corporate links
2) residential DSL/cable where P2P apps are being used
others?

This also assumes the new RTP flow is CBR (which isn't a bad assumption for
audio VoIP).

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Nov 2006 08:35:00 +0000

On 1 Nov 2006, at 22:29, Randell Jesup wrote:
> I'd be interested too; I haven't really seen this.

Likewise. I can imagine scenarios where it might happen, but it's not  
something I've seen in the tests I've run. More details would be  
interesting, to understand how widespread a problem this is.

Colin

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 7 Nov 2006 17:02:33 +0200

Hi
On
"Except those middleboxes may well reject unknown packets on the RTP
port.
And in any case, we're putting bandaids on bandaids here - and even with
this, there are serious bandwidth issues."

So if we are on the what if ...

So what happens if the offer starts with a sendonly offer on the media,
putting the remote side on hold, the middle box may decide to throw away
all packets sent from the other side since the offer was for a sendonly
so no SRTP kaye since ZRTP needs the bi-direction while RTP does not
mandate it. Note that RTCP is bi-direction even if the RTP is
uni-directional.

Roni Even

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:19 PM
> To: Colin Perkins
> Cc: [email-masked]; Dan Wing
> >> You could mandate support for RTCP-on-RTP even if not signalled,
> perhaps.
> >
> >You could certainly mandate that ZRTP messages are sent as RTCP on
the
> RTP
> >port, irrespective of the signalling, until the middleboxes  are
> >fixed. It's not ideal, but it doesn't break the architecture, and
those
> >middleboxes will eventually be fixed to support "a=rtcp:".
> 
> Except those middleboxes may well reject unknown packets on the RTP
port.
> And in any case, we're putting bandaids on bandaids here - and even
with
> >> I admit, I like the idea of RTCP, but I don't see how we can avoid
> badly
> >> breaking the RTCP rules.  If everyone is willing to break them for
> this,
> >> and it doesn't mean another horrible mess like AVPF/SAVPF has
turned
> into
> >> (because of SDP and how profiles are negotiated), ok.
> >
> >I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the
> >initial negotiation, than for it to embed control information into
RTP
> alternative
> >architecturally, given that the community seems to have  decided to
punt
> >the keying problem onto this group, rather than  fixing the SIP
layer.
> 
> Ignoring the timing rules, or timing aFrom [email-masked] Tue Nov 07 10:03:25 2006
Content-class: urn:content-classes:message
Subject: RE: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]
Date: Tue, 7 Nov 2006 17:02:33 +0200
From: "Even, Roni" <[email-masked]>
To: "Randell Jesup" <[email-masked]>,
	"Colin Perkins" <[email-masked]>
Cc: [email-masked], Dan Wing <[email-masked]>

Hi
On
"Except those middleboxes may well reject unknown packets on the RTP
port.
And in any case, we're putting bandaids on bandaids here - and even with
this, there are serious bandwidth issues."

So if we are on the what if ...

So what happens if the offer starts with a sendonly offer on the media,
putting the remote side on hold, the middle box may decide to throw away
all packets sent from the other side since the offer was for a sendonly
so no SRTP kaye since ZRTP needs the bi-direction while RTP does not
mandate it. Note that RTCP is bi-direction even if the RTP is
uni-directional.

Roni Even

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2006 9:19 PM
> To: Colin Perkins
> Cc: [email-masked]; Dan Wing
> >> You could mandate support for RTCP-on-RTP even if not signalled,
> perhaps.
> >
> >You could certainly mandate that ZRTP messages are sent as RTCP on
the
> RTP
> >port, irrespective of the signalling, until the middleboxes  are
> >fixed. It's not ideal, but it doesn't break the architecture, and
those
> >middleboxes will eventually be fixed to support "a=rtcp:".
> 
> Except those middleboxes may well reject unknown packets on the RTP
port.
> And in any case, we're putting bandaids on bandaids here - and even
with
> >> I admit, I like the idea of RTCP, but I don't see how we can avoid
> badly
> >> breaking the RTCP rules.  If everyone is willing to break them for
> this,
> >> and it doesn't mean another horrible mess like AVPF/SAVPF has
turned
> into
> >> (because of SDP and how profiles are negotiated), ok.
> >
> >I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the
> >initial negotiation, than for it to embed control information into
RTP
> alternative
> >architecturally, given that the community seems to have  decided to
punt
> >the keying problem onto this group, rather than  fixing the SIP
layer.
> 
> Ignoring the timing rules, or timing and bandwidth?  If you're
ignoring
> bandwidth rules, you probably won't work in a QoS-enabled network.
(For
> example, cable companies sniff SDP to do QoS reservation over
PacketCable
> for SIP traffic; if you violate the limits your packets will either be
> 
> delayed or quite possibly dropped.)  Obviously it would also affect
> wireless QoS links as well (802.11e, for example).  Etc, etc.
> 
> And "violating" the RTCP rules (either AVP or AVPF rules) requires a
new
> profile by IETF standards.  (And yet more combinatorial profile
explosion,
> and excessive fun in call setup...)
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> [email-masked]
> "The fetters imposed on liberty at home have ever been forged out of
the
> weapons
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 7 Nov 2006 17:02:32 +0200

Hi,
I think that saying that RTCP does not work through SBCs is a nice
comment but that will mean that those SBCs will not work when video is
working so they are broken. 
In the video case CCM draft has fastupdate and flow control command
without which you will not get a good video. So if the community thinks
that SIP video conferencing is part of telecommunication including in 3G
network then RTCP support is a must.

Roni Even

> Sent: Monday, October 30, 2006 7:20 PM
> To: Colin Perkins
> >> Multiplex in Colin's draft requires a=rtcp support currently
(though I
> >> have a few issues with that still (I think)).  That means that to
> >> exchange keys, the endpoints need to negotiate a viable RTCP
connection
> >> (normal or multiplex). nd bandwidth?  If you're
ignoring
(For
PacketCable
new
explosion,
OS
the
from

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 7 Nov 2006 17:02:32 +0200

Hi,

Roni Even

(though I
connection
> >> (normal or multiplex).  If multiplex, any network elements in the
media
> >> stream need to pass the RTCP properly, AND need to not break a=rtcp
> >> (which is one of my problems with it - some will break it by
ignoring
> >> it).
> >
> >ICE also requires "a=rtcp:" support, so I expect it to be widely
> deployed
> >in the not-too-distant future.
> 
> Uh... yeah.  Depends on how you define "not-too-distant".  The kicker
is
> that all these existing network elements that will not work with it
(SBCs
> mostly), and from experience many of them are often running
> far-from-up-to-date software, or are written in-house, buggy, etc.
Lots
> of
> them don't even *pass* RTCP, let along support a=rtcp.
> 
> >And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP
> port
> >without signalling, than always sending control messages in the  RTP
> >stream. Updating middlebox implementations to support "a=rtcp:"  is
much
> >easier than fixing a broken architecture that mixes control  plane
and
> data
> >plane.
> 
> Um, how will it get sent on the RTP port?  To the receiver, it will
look
> like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on
> (ignored by SBC) port bar.  And the receiver will happily comply, and
> their
> RTCP packets will go into the bit-bucket.  Maybe the implementations
can
> notice the problems or use a side-channel to suss out what the SBC
> (didn't)
> do, but I wouldn't bet encryption on it.
> 
perhaps.
> 
> >>> I don't see that being a problem.
> >>
> >> Why is that not a problem?  If you have a more-typical 24K
(including
> >> overhead) G.729 stream you only have 1200 bits for RTCP - and from
that
> >> you have to subtract an RR or SR, a header, etc.  And more
importantly,
> >> without AVPF you need longer intervals between individual RTCPs
(though
> >> perhaps some of those are SHOULD not MUST).  There's nothing about
"but
> >> at startup it's OK to ignore the rules", or "only applies if media
is
> >> flowing" in RTCP.
> >
> >Sure, but again, a minor change to the RTCP timing rules to allow
ZRTP
> is
> >much preferable to a major architectural change to allow  control
> messages
> >within an RTP data stream.
> 
> Isn't this the same sort of "minor timing change" that required an
entire
> new set of N profiles (i.e. AVPF)?  And this wouldn't fit in the AVPF
> rules, so we'd have to have AVPZ... 1/2 :-)
> 
badly
this,
> and it doesn't mean another horrible mess like AVPF/SAVPF has turned
into
> >> Realize, I like the idea of using RTCP for the key exchange here.
But
> >> there are issues to address, including issues of network element
> support
> >> for AVPF (which looks like it would be required).
> >>
> >> There are other options:
> >> *Use a separate media (m=data) stream for key exchanges.  There are
> some
> >>  obvious issues since it's now separate from the media ports, and
some
> >>  elements might not like another port (pair) being allocated.
> >
> >Reasonable, but would need signalling support and extra ports.
> 
> This probably could be done.  Yes, it requires another port-pair. (In
> theory I don't think there's anything *mandating* that a set of media
> streams use different ports - but people want to use that as a way to
try
> to do profile negotiation.)
> 
> >> *Use the same media stream, but with the initial payload being ZRTP
> data.
> >>  (a=rtpmap:99 ZRTP).  Exchange data as payload type 99, then start
> >>  sending encrypted data using one of the other payload types.  This
is
> >>  also an intriguing option, and doesn't need extra ports or a=rtcp
or
> >>  AVPF support.
> >
> >It's architecturally pretty ugly: a media stream shouldn't contain
> control
> >data. I would much prefer RTCP, whether signalled or not, or  another
> >protocol that is multiplexed on the same port (as done with  STUN) If multiplex, any network elements in the
media
> >> stream need to pass the RTCP properly, AND need to not break a=rtcp
> >> (which is one of my problems with it - some will break it by
ignoring
> >> it).
> >
> >ICE also requires "a=rtcp:" support, so I expect it to be widely
> deployed
> >in the not-too-distant future.
> 
> Uh... yeah.  Depends on how you define "not-too-distant".  The kicker
is
> that all these existing network elements that will not work with it
(SBCs
> mostly), and from experience many of them are often running
> far-from-up-to-date software, or are written in-house, buggy, etc.
Lots
> of
> them don't even *pass* RTCP, let along support a=rtcp.
> 
> >And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP
> port
> >without signalling, than always sending control messages in the  RTP
> >stream. Updating middlebox implementations to support "a=rtcp:"  is
much
> >easier than fixing a broken architecture that mixes control  plane
and
> data
> >plane.
> 
> Um, how will it get sent on the RTP port?  To the receiver, it will
look
> like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on
> (ignored by SBC) port bar.  And the receiver will happily comply, and
> their
> RTCP packets will go into the bit-bucket.  Maybe the implementations
can
> notice the problems or use a side-channel to suss out what the SBC
> (didn't)
> do, but I wouldn't bet encryption on it.
> 
perhaps.
> 
> >>> I don't see that being a problem.
> >>
> >> Why is that not a problem?  If you have a more-typical 24K
(including
> >> overhead) G.729 stream you only have 1200 bits for RTCP - and from
that
> >> you have to subtract an RR or SR, a header, etc.  And more
importantly,
> >> without AVPF you need longer intervals between individual RTCPs
(though
> >> perhaps some of those are SHOULD not MUST).  There's nothing about
"but
> >> at startup it's OK to ignore the rules", or "only applies if media
is
> >> flowing" in RTCP.
> >
> >Sure, but again, a minor change to the RTCP timing rules to allow
ZRTP
> is
> >much preferable to a major architectural change to allow  control
> messages
> >within an RTP data stream.
> 
> Isn't this the same sort of "minor timing change" that required an
entire
> new set of N profiles (i.e. AVPF)?  And this wouldn't fit in the AVPF
> rules, so we'd have to have AVPZ... 1/2 :-)
> 
badly
this,
> and it doesn't mean another horrible mess like AVPF/SAVPF has turned
into
> >> Realize, I like the idea of using RTCP for the key exchange here.
But
> >> there are issues to address, including issues of network element
> support
> >> for AVPF (which looks like it would be required).
> >>
> >> There are other options:
> >> *Use a separate media (m=data) stream for key exchanges.  There are
> some
> >>  obvious issues since it's now separate from the media ports, and
some
> >>  elements might not like another port (pair) being allocated.
> >
> >Reasonable, but would need signalling support and extra ports.
> 
> This probably could be done.  Yes, it requires another port-pair. (In
> theory I don't think there's anything *mandating* that a set of media
> streams use different ports - but people want to use that as a way to
try
> to do profile negotiation.)
> 
> >> *Use the same media stream, but with the initial payload being ZRTP
> data.
> >>  (a=rtpmap:99 ZRTP).  Exchange data as payload type 99, then start
> >>  sending encrypted data using one of the other payload types.  This
is
> >>  also an intriguing option, and doesn't need extra ports or a=rtcp
or
> >>  AVPF support.
> >
> >It's architecturally pretty ugly: a media stream shouldn't contain
> control
> >data. I would much prefer RTCP, whether signalled or not, or  another
> >protocol that is multiplexed on the same port (as done with  STUN).
> 
> Well, I think this is architecturally much better than the header
> extension/NOOP idea, avoids the RTCP BW limit issues, doesn't conflict
> with
> hdrext, avoids SSRC issues, etc.  It provides a negotiated (you can
reject
> it) media-path control-plane for this specific purpose with no
bandwidth
> limitations and less overhead than RTCP (no RR/SR).  The major
downside
> architecturally is that the data in the packets is not per-se audio or
> video (or whatever m=data type), but what the packets contain is being
> signalled.  It doesn't interfere with existing applications, should be
> totally transparent to all but the worst-written network elements, and
> doesn't interfere with normal traffic/packet-sizes/RTCP
calculations/etc.
> 
> Multiplexing another protocol in the same port as RTP is an option, of
> course, though probably more network elements would block it than
would
> the payload idea.  I would probably consider that as the strongest
> alternative to the payload idea above, and put both above the current
> header-extension/NOOP plan.  I prefer the payload plan because it
avoids
> some issues with the application having to intuit the type of incoming
> packets, and in general it just seems odd to me.  I know why it was
needed
> for ICE/STUN, from a technical point of view, but that's not needed
here.
OS
the
from

.
> 
> Well, I think this is architecturally much better than the header
> extension/NOOP idea, avoids the RTCP BW limit issues, doesn't conflict
> with
> hdrext, avoids SSRC issues, etc.  It provides a negotiated (you can
reject
> it) media-path control-plane for this specific purpose with no
bandwidth
> limitations and less overhead than RTCP (no RR/SR).  The major
downside
> architecturally is that the data in the packets is not per-se audio or
> video (or whatever m=data type), but what the packets contain is being
> signalled.  It doesn't interfere with existing applications, should be
> totally transparent to all but the worst-written network elements, and
> doesn't interfere with normal traffic/packet-sizes/RTCP
calculations/etc.
> 
> Multiplexing another protocol in the same port as RTP is an option, of
> course, though probably more network elements would block it than
would
> the payload idea.  I would probably consider that as the strongest
> alternative to the payload idea above, and put both above the current
> header-extension/NOOP plan.  I prefer the payload plan because it
avoids
> some issues with the application having to intuit the type of incoming
> packets, and in general it just seems odd to me.  I know why it was
needed
> for ICE/STUN, from a technical point of view, but that's not needed
here.
OS
the
from