Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp - TCP "reliable delivery"

From: "Marc Lampo" <[email-masked]>
Date: Mon, 1 Aug 2011 16:42:56 +0200 (CEST)

Last week I had a very brief talk with the presenter of this draft,
promising to post a follow-up on the list.

In 4.9.1. the present document states :
"TCP provides an in-order reliable delivery of a stream of bytes."

This statement is kind of ambiguous,
depending if one looks from the senders or receivers perspective !

The point is that TCP does not guarantee that data sent, by sending
application,
will actually make it, to the receiving application.
The only thing that is guaranteed is that
"if a byte is received by an application,
 it is in-order and correct." (with emphasis on the first *if* !)

This observation is not so important for this particular draft,
but :
because UDP does not reliably deliver data,
some protocol changes, to BFCP, are proposed in this draft.
(like making explicit ACK messages mandatory,
 introduction of timers).

>From that "introduction" of these protocol changes,
I deduce that these are not present when the transport protocol is layer
4.
And *that* is weird !
There are certainly conditions in which TCP will fail to deliver,
and explicit "ACK" (in layers 5+, so to say) and time-out protection
are required for reliable operation.
If missing, I'd say this protocol is running in quite "protected"
environments indeed.

Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150    
    1831 Diegem - Belgium
    [email-masked]
    http://www.eurid.eu

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 8 Aug 2011 13:37:15 +0300

Hi,

yes, that is a good point. Providing application-level ack messages for
reliability has the effect of making those acks visible at the
application layer (instead of being only visible at the transport layer,
which is the case when TCP is used).

I agree the draft needs to discuss this. When we originally designed
BFCP, we chose not to provide application-level acks for some messages
in order to be able to use BFCP in environments with tight bandwidth and
delay requirements (at that time, the push to talk over cellular service
was the main example of those environments).

Cheers,

Gonzalo

On 01/08/2011 5:42 PM, Marc Lampo wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>