Subject: Re: [bfcpbis] More comments on RFC 4582

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 4 Jun 2012 13:15:29 +0200

<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.

> > 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.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Tom Kristensen <[email-masked]>
Date: Mon, 04 Jun 2012 15:16:30 +0200

> implementation: I don't think the spec needs to say anything about that
Agree. And if there's no demand here in BFCPbis, no text will be added 
for this issue.

>> Tom: We've solved the fragmentation issue. No demands voiced for length exceeding the maximum message length for reliable transport voiced in BFCPbis.
>>      
>
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

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 4 Jun 2012 15:33:51 +0200

Il giorno Mon, 04 Jun 2012 15:16:30 +0200
Tom Kristensen <[email-masked]> ha scritto:

> > 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.
> 
> >> 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
> > 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.

---

From: "Chelliah Sivachelvan (chelliah)" <[email-masked]>
Date: Mon, 4 Jun 2012 07:22:19 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Kristensen (tomkrist)
Sent: Monday, June 04, 2012 8:17 AM
To: Lorenzo Miniero
Cc: [email-masked]; Tom Kristensen; Gonzalo Camarillo
Subject: Re: [bfcpbis] More comments on RFC 4582

> implementation: I don't think the spec needs to say anything about
that

> I'm not sure how the problem may be solved: I guess setting the
version

-- Tom
_______________________________________________
bfcpbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 05 Jun 2012 07:53:57 +0200

>        before it receives the answer.]
Yes, this is true for DTLS usage (UDP/TLS/BFCP). However, the example is 
the original example from RFC 4582 related to TLS (TCP/TLS/BFCP). So I 
believe the example in rfc4583bis is correct!

-- Tom

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 5 Jun 2012 10:19:14 -0700

I agree, however, perhaps it would be useful to add a second example in
which an endpoint initiates the offer and uses DTLS; e.g.:

Offer from client:

   m=application 50000 UDP/DTLS/BFCP *
   a=setup:actpass
   a=fingerprint:SHA-1 \
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=floorctrl:c-only, s-only
   a=confid:4321
   a=userid:1234	
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

The following is the answer returned by the server.

   m=application 9 UDP/DTLS/BFCP *
   a=setup:active
   a=fingerprint:SHA-1 \
        3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234	
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   m=audio 55000 RTP/AVP 0
   m=video 55002 RTP/AVP 31

Cheers,
Charles

> Sent: Monday, June 04, 2012 10:54 PM
> To: Chelliah Sivachelvan (chelliah)
> Cc: Lorenzo Miniero; [email-masked]; Tom Kristensen; Gonzalo
> Camarillo
> Subject: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on
> RFC 4582
>

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 06 Jun 2012 07:50:07 +0200

Sure, a good idea to add an accompanying DTLS example. If no objections 
are received, this will be part of the next version of the draft.

-- Tom

On 06/05/2012 07:19 PM, Charles Eckel (eckelcu) wrote:
>>> 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
>>

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 06 Jun 2012 10:32:50 +0200

Just for the record:
Will change Charles' UDP/DTLS/BFCP in the example below ==> UDP/TLS/BFCP.

-- Tom

On 06/06/2012 07:50 AM, Tom Kristensen wrote:
> Sure, a good idea to add an accompanying DTLS example. If no 
> objections are received, this will be part of the next version of the 
> draft.
>
> -- Tom
>