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