Re: [bfcpbis] More comments on RFC 4582
"Chelliah Sivachelvan (chelliah)" <chelliah@cisco.com> Mon, 04 June 2012 14:22 UTC
Return-Path: <chelliah@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF821F88C4 for <bfcpbis@ietfa.amsl.com>; Mon, 4 Jun 2012 07:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve9I6uf1Wx1a for <bfcpbis@ietfa.amsl.com>; Mon, 4 Jun 2012 07:22:24 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F085521F88C8 for <bfcpbis@ietf.org>; Mon, 4 Jun 2012 07:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=chelliah@cisco.com; l=3208; q=dns/txt; s=iport; t=1338819744; x=1340029344; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cOQJd5/vx9AhHCaThEen1xAU/lzOzESWBPOSNJmf3Mg=; b=CR9uVWIpRvHWo4741z90Dq8+qkYOZG+PsucoB2Jr77nbaxj42xHaERZ3 ey3/Rosc9V7rxq8fktaq2yibeLylNwm4lsklKe3AFLn0z78xMG2dMNhxw 8mtH/UZQLJGO094a9hvR4Y0jhQSi4rPs4AGtMznWmUHgOmHAmMgyGddwK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAPTDzE+rRDoG/2dsb2JhbABEtCiBB4IYAQEBAwEBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBMHh2QEAQuXDp8lBIsRhTBgA4hAmmuBZoMA
X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="scan'208";a="45003919"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Jun 2012 14:22:23 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q54EMNKP012445; Mon, 4 Jun 2012 14:22:23 GMT
Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 07:22:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Jun 2012 07:22:19 -0700
Message-ID: <A997DBD5DD3E0B46A6D0353CF3E32CCB0FE3D87D@xmb-sjc-233.amer.cisco.com>
In-Reply-To: <4FCCB52E.5010109@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [bfcpbis] More comments on RFC 4582
Thread-Index: Ac1CVEYaW6qX7aFrSOCCIIR4ypHvegACRorg
References: <20120604131529.133a66fa@lminiero-acer> <4FCCB52E.5010109@cisco.com>
From: "Chelliah Sivachelvan (chelliah)" <chelliah@cisco.com>
To: "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>, Lorenzo Miniero <lorenzo@meetecho.com>
X-OriginalArrivalTime: 04 Jun 2012 14:22:23.0183 (UTC) FILETIME=[7559E5F0:01CD425D]
Cc: bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [bfcpbis] More comments on RFC 4582
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2012 14:22:25 -0000
Tom, A minor comment on the SDP example in section 9. In the context of DTLS, the setup a line must be "actpass" in the offer. See excerpts from RFC 5763: [ The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer.] Thanks! Chelliah -----Original Message----- From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Tom Kristensen (tomkrist) Sent: Monday, June 04, 2012 8:17 AM To: Lorenzo Miniero Cc: bfcpbis@ietf.org; Tom Kristensen; Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 On 06/04/2012 01:15 PM, Lorenzo Miniero wrote: > <snipping here and there> > > >>> o When we get more experience on queue management from real >>> deployments, it would be nice to explaining it further in the spec. >>> >> Tom: I have no knowledge of queue management from deployments. >> Does anyone else out there have any deployment experience? If not, >> we don't really have much to add at present. >> >> > > We don't do anything fancy with queue management in our current > implementation: I don't think the spec needs to say anything about that > anyway. > Agree. And if there's no demand here in BFCPbis, no text will be added for this issue. >>> o A message may need to be longer than the maximum message length >>> supported by the protocol >>> >> Tom: We've solved the fragmentation issue. No demands voiced for length exceeding the maximum message length for reliable transport voiced in BFCPbis. >> > > I was one of those bringing this issue to the ML, back in the days: I > think the solution proposed in this new document could correctly > address the problem not only when using unreliable connections, but > reliable ones too. The only concern I have, though, is that the draft > currently says that, when using TCP, the version bit must be set to 1 > as per RFC4582: this means that involved entities will get confused > about the new fragment part of the header. Legacy implementations > instead would definitely fail when fragmentation is involved, since the > overall length would now match the actual payload containing the first > fragment. > > I'm not sure how the problem may be solved: I guess setting the version > to 2 for reliable connections might be a way, whereas in that case the > only new "feature" to be used would be the fragmentation stuff and not > the whole spec. > My hope is that this kind of fragmentation, due to the existing payload length field in the BFCP messages being 16 bit, could be avoided by pointing at BFCP's usage domain ("small messages...") and if needed recommend using other means for distributing laaaarge messages (SIP Event framework, other conferencing protocols, ...). Note that the BFCP common header payload length field is a 16-bit field that contains the length of the message in 4-octet units. -- Tom _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis
- [bfcpbis] More comments on RFC 4582 Gonzalo Camarillo
- Re: [bfcpbis] More comments on RFC 4582 Tom Kristensen
- Re: [bfcpbis] More comments on RFC 4582 Charles Eckel (eckelcu)
- Re: [bfcpbis] More comments on RFC 4582 Lorenzo Miniero
- Re: [bfcpbis] More comments on RFC 4582 Tom Kristensen
- Re: [bfcpbis] More comments on RFC 4582 Lorenzo Miniero
- Re: [bfcpbis] More comments on RFC 4582 Chelliah Sivachelvan (chelliah)
- [bfcpbis] rfc4583bis TLS SDP example - Re: More c… Tom Kristensen
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Charles Eckel (eckelcu)
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Tom Kristensen
- Re: [bfcpbis] rfc4583bis TLS SDP example - Re: Mo… Tom Kristensen