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