Re: [bfcpbis] More comments on RFC 4582
Lorenzo Miniero <lorenzo@meetecho.com> Mon, 04 June 2012 13:34 UTC
Return-Path: <lorenzo@meetecho.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 D34FC21F87E9 for <bfcpbis@ietfa.amsl.com>; Mon, 4 Jun 2012 06:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 OSPF2JeoHu3H for <bfcpbis@ietfa.amsl.com>; Mon, 4 Jun 2012 06:34:00 -0700 (PDT)
Received: from smtplq03.aruba.it (smtplq-out14.aruba.it [62.149.158.34]) by ietfa.amsl.com (Postfix) with SMTP id AA80C21F87E7 for <bfcpbis@ietf.org>; Mon, 4 Jun 2012 06:33:59 -0700 (PDT)
Received: (qmail 502 invoked by uid 89); 4 Jun 2012 13:33:57 -0000
Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq03.aruba.it with SMTP; 4 Jun 2012 13:33:57 -0000
Received: (qmail 21014 invoked by uid 89); 4 Jun 2012 13:33:57 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp8.ad.aruba.it with SMTP; 4 Jun 2012 13:33:57 -0000
Date: Mon, 04 Jun 2012 15:33:51 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Tom Kristensen <tomkrist@cisco.com>
Message-ID: <20120604153351.0e67d77a@lminiero-acer>
In-Reply-To: <4FCCB52E.5010109@cisco.com>
References: <20120604131529.133a66fa@lminiero-acer> <4FCCB52E.5010109@cisco.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N
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 13:34:00 -0000
Il giorno Mon, 04 Jun 2012 15:16:30 +0200 Tom Kristensen <tomkrist@cisco.com> ha scritto: > 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 You're right, the scenario I had in mind at the time was probably an edge case that could be solved some other way anyway, as you pointed out. L. -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com
- [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