Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 25 Jul 2011 18:05:08 +0200

So just to amplify my comment in the meeting.

BFCP was designed so that all requests and responses were sent reliably, i.e. that responses had the same level of protection provided by the underlying TCP that the requests had.

This means that the responses can also carry data, with the same assumption that the underlying layer will ensure that the response is received.

What this draft appears to be assuming is that the responses are there only to acknowledge the requests, and therefore adding responses to the requests that do not have them is sufficient. That is incorrect. Responses are there because the response carries data that was requested in the request.

Now while it may not be that all data in responses is essential to receive, it does change the future extensions status of BFCP, in that we now need to ask exactly the same question we ask everytime we  need to proposa data in responses in SIP, i.e. what happens if the data in the response is lost. We should not have to have such questions in BFCP.

Keith

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 08:19:16 -0700

Hi Keith,

You raise a very valid point. Sorry if it seemed to get glossed over in
the WG session. I agree that we need to look at this carefully. There
are several ways to address it including:
- additional explicit ACK messages
- additional timers and/or timer expiration handling requirements
I believe we already have these to the extent they are required for the
SIP videoconference use case described in the draft, but we need to take
a more thorough look at it.
If you have any suggestions for solutions, I'd love to hear them.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, July 25, 2011 12:05 PM
> To: [email-masked]
> Subject: [dispatch] draft-sandbakken-dispatch-bfcp-udp-02.txt
> 
> BFCP was designed so that all requests and responses were sent
reliably, i.e. that responses had the
> same level of protection provided by the underlying TCP that the
requests had.
> 
> This means that the responses can also carry data, with the same
assumption that the underlying layer
> will ensure that the response is received.
> 
> What this draft appears to be assuming is that the responses are there
only to acknowledge the
> requests, and therefore adding responses to the requests that do not
have them is sufficient. That is
> incorrect. Responses are there because the response carries data that
was requested in the request.
> 
> Now while it may not be that all data in responses is essential to
receive, it does change the future
> extensions status of BFCP, in that we now need to ask exactly the same
question we ask everytime we
> need to proposa data in responses in SIP, i.e. what happens if the
data in the response is lost. We
> should not have to have such questions in BFCP.
> 
> Keith
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch