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

Randell Jesup <rjesup@wgate.com> Tue, 31 October 2006 12:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesUb-0005oN-Qa; Tue, 31 Oct 2006 07:13:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesUb-0005oI-AU for avt@ietf.org; Tue, 31 Oct 2006 07:13:21 -0500
Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesUR-0000Bk-AL for avt@ietf.org; Tue, 31 Oct 2006 07:13:21 -0500
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:13:11 -0500
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]
References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <E5854D04-48CD-48EF-AE03-EAA077CA46E0@csperkins.org> <ybuk62iqydx.fsf@jesup.eng.wgate.com> <AC2BB1B4-7BFA-4F11-B5C0-275BDF05E59C@csperkins.org> <ybu8xix3ema.fsf@jesup.eng.wgate.com> <454721D4.3030408@ericsson.com>
From: Randell Jesup <rjesup@wgate.com>
Date: Tue, 31 Oct 2006 07:13:09 -0500
In-Reply-To: <454721D4.3030408@ericsson.com> (Magnus Westerlund's message of "Tue, 31 Oct 2006 11:13:40 +0100")
Message-ID: <ybuiri0isyy.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 31 Oct 2006 12:13:11.0129 (UTC) FILETIME=[EED51490:01C6FCE5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Colin Perkins <csp@csperkins.org>, Dan Wing <dwing@cisco.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Magnus Westerlund <magnus.westerlund@ericsson.com> writes:
>Generally I am agreeing with Colin here. Putting ZRTP handshake into RTCP
>is a clean solution. When it comes to broken boxes, like SBC I think it is
>fine to consider them but we shouldn't change everything simply to
>accommodate them. They are after all broken if they aren't supporting
>RTCP. Too broken boxes will need to be upgraded.

Sure, but it won't happen overnight.

>In regards to the bandwidth. Independent on if the handshake happens in RTP
>or RTCP there needs to be some checks on the bit-rate. We can't ignore
>congestion control when being deployed on a best effort network. Thus ZRTP
>should take care not to require completion within a specific time. Because
>the transfer of particular amount of data may take some time.

Sure.  Also (and I know they know this) handling packet loss.

>So thinking that RTP will be better than RTCP in this regard may very well
>be an illusion. Also I think people are very looked into the 5% BW rule
>instead of considering what RR and RS bandwidth modifier combined with
>AVPF actually can accomplish. For example RTCP can be configured to have
>low average BW and still allow substantially higher rates when needed.

If you configure it for high RR/RS, then normal RTCP for the rest of the
call can use a lot, and more importantly QoS network elements have to
reserve that bandwidth for the entire call, whether or not it's used.
This is a huge restriction on RTCP for many usages.  The effect would be
that it could take several seconds (ignoring packet loss) to exchange
keys.  In some cases perhaps 10 seconds.  Admittedly, these are large
key exchanges, but even if trimmed somehow I think it's still way too long
(not just a little too long).

>Also I wonder how well ZRTP handles the mixer translator cases. I am sorry
>to say that I haven't read the latest ZRTP version. However I will try to
>do it before the meeting. Have the authors consider the example of
>topologies that can be existing as described in
>http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-02.txt

I haven't either, but I suspect a payload-type-based solution will handle
mixers (and other cases being considered) as well as RTCP.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"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)


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt