Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 4 Jun 2012 07:22:19 -0700
Message-ID: <A997DBD5DD3E0B46A6D0353CF3E32CCB0FE3D87D@xmb-sjc-233.amer.cisco.com>
In-Reply-To: <4FCCB52E.5010109@cisco.com>
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>
Cc: bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>,
 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [bfcpbis] More comments on RFC 4582
Precedence: list

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>
>
>   =20
>>> o When we get more experience on queue management from real
>>> deployments, it would be nice to explaining it further in the spec.
>>>       =20
>> 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.
>>
>>     =20
>
> 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.
>   =20
Agree. And if there's no demand here in BFCPbis, no text will be added=20
for this issue.

>>> o A message may need to be longer than the maximum message length
>>> supported by the protocol
>>>       =20
>> Tom: We've solved the fragmentation issue. No demands voiced for
length exceeding the maximum message length for reliable transport
voiced in BFCPbis.
>>     =20
>
> 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.
>   =20
My hope is that this kind of fragmentation, due to the existing payload=20
length field in the BFCP messages being 16 bit, could be avoided by=20
pointing at BFCP's usage domain ("small messages...") and if needed=20
recommend using other means for distributing laaaarge messages (SIP=20
Event framework, other conferencing protocols, ...).

Note that the BFCP common header payload length field is a 16-bit field=20
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