Re: [bfcpbis] More comments on RFC 4582

[Lorenzo Miniero <[e-mail]>]

<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