Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck?

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 19 Jun 2012 11:58:21 -0700

(as an individual) 

Hi Ernst,

This is a good question. Looking at RFC 4582, table 1 shows the Error
primitive as being for Server to Client/Participant only. The details in
section 5.3.1.13 and the rest of the RFC are consistent with this. In
all cases, the Error primitive from the server is in response to a
client request primitive. Section 13.8 states:

13.8.  Error Message Generation

   Error messages are always sent in response to a previous message from
   the client as part of a client-initiated transaction.

The changes made to address unreliable transport in
draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error
primitive may be sent by either a client or a server. These scenarios
include invalid payload length and not being able to parse a BFCP
message in general. I believe the tables and corresponding sections in
RFC 4582 need to be updated to reflect this change consistently.
As for the ErrorAck message, while it could be argued that it is not
strictly necessary, the bis draft does consistently state it as being
required. The main benefit is that it allows both sides to unambiguously
complete the transaction. I believe the corresponding text is okay as
is.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Horvath, Ernst
> Sent: Friday, June 15, 2012 5:56 AM
> To: [email-masked]
> Subject: [bfcpbis] RFC4582bis: What is the transaction model
> behindError/ErrorAck?
> 
> Hi,
> 
> I have a problem understanding the use of ErrorAck.
> 
> For unreliable transport RFC4582bis describes two transaction types:
> 
> 1) Client-initiated: A client (chair or participant) sends a request
to the
> server and receives a Status or an Error message back; the client runs
T1 and
> retransmits the request if no response arrives in time, but the server
does
> not run T1 and does not retransmit the response (Status or Error)
unless
> triggered by receipt of a retransmitted request. The client does not
send a
> StatusAck for the response.
> 
> 2) Server-initiated: The server sends a notification (i.e. a follow-up
status
> message) to the client and receives a StatusAck back. The server runs
T1 and
> retransmits the notification if no StatusAck arrives, but the client
does not
> retransmit the StatusAck unless triggered by a retransmitted
notification.
> (Question: Can the client send an Error message instead of StatusAck?
Error
> seems to be reserved for the direction server to client, but the draft
is not
> 100% clear about that.)
> 
> Now, how does ErrorAck fit in? Error is the backward message in a
two-step
> (request/reponse) transaction model, and BFCPbis did not introduce a
> three-step (request/response/ack) model, right? Or can Error be used
as a
> transaction-initiating request, with ErrorAck forming the response? If
so,
> this is currently not described.
> 
> Regards,
> Ernst Horvath
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: "Horvath, Ernst" <[email-masked]>
Date: Wed, 20 Jun 2012 07:18:22 +0000

Charles, 

Well, I did not find answers in the existing text to questions such as:

- Is ErrorAck sent in reply to every Error message, or only in some cases?
- Which transaction ID is used in ErrorAck? I assume the one from the original request, but then we would have the 3-stage transaction model I mentioned in my original mail. 
- Would the sender retransmit the Error message if it does not receive ErrorAck? Then the sender would need to keep state and run timer T1 for responses, which is currently not described.
- Can Error create its own transaction, using a new transaction ID, e.g. if a datagram could not be parsed?

I guess some additional text is needed to clarify the use of Error/ErrorAck in general, and maybe some specific failure scenarios deserve their own description.  

Regards,
Ernst

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: Dienstag, 19. Juni 2012 20:58
> To: Horvath, Ernst; [email-masked]
> Subject: RE: [bfcpbis] RFC4582bis: What is the transaction 
> model behindError/ErrorAck?
> 
> (as an individual) 
> 
> Hi Ernst,
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 21 Jun 2012 22:29:08 +0000

Hi Ernst,

I agree with you that specification of Error and ErrorAck within this draft needs some work. When I stated that the corresponding text was okay as is, I meant that in regard to the sending of ErrorAck primitives only. However, upon closer inspection, I am reconsidering. 
In RFC 4582, the Error message is always a response, as you correctly pointed out. As such, there is not a real need for an ErrorAck. This is similar to the FloorRelease/FloorRequestStatus exchange. In this case, a FloorRequestStatusAck is not necessary. Similarly, if a server responds to a client initiated transaction message with an Error, that should complete the transaction without the need for an ErrorAck.
The current draft includes new cases in which an Error message may be sent, including upon receiving a message with invalid payload length or an unsupported BFCP version. You correctly point out that the usage of Error/ErrorAck in these scenarios is underspecified. I'd like to propose that we restrict this new usage as well to cases in which a server is responding to a client initiated transaction. I believe this remains consistent with the spirit of the Error message in RFC 4582 and removes the need for the ErrorAck.

Cheers,
Charles

> From: Horvath, Ernst [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2012 12:18 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [bfcpbis] RFC4582bis: What is the transaction model
> behindError/ErrorAck?
> 
> Charles,
> 

For each Error messages. My suggested change to section 13.9 is as follows:

   When communicating over unreliable transport and upon receiving an
   Error message from a floor control server, the participant MUST
   respond with a ErrorAck message within the transaction failure window
   to complete the transaction.

Change to:

   When communicating over unreliable transport and upon receiving an
   Error message, the recipient MUST respond with a ErrorAck message 
   within the transaction failure window to complete the transaction.

> - Which transaction ID is used in ErrorAck? I assume the one from the
> original request, but then we would have the 3-stage transaction model I
> mentioned in my original mail.

The transaction ID should match that specified in the Error message.

> - Would the sender retransmit the Error message if it does not receive
> ErrorAck? Then the sender would need to keep state and run timer T1 for
> responses, which is currently not described.
> I guess some additional text is needed to clarify the use of Error/ErrorAck in
> general, and maybe some specific failure scenarios deserve their own
> description.
> 
> Regards,
> Ernst
> 
>

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 22 Jun 2012 15:18:27 +0200

I concur with the conclusions here, the ErrorAck does not have any 
actual need and use. So thanks to Ernst for spotting this issue and to 
Charles for analysis.

Given no protests over the weekend, the ErrorAck will be removed from 
the next draft version.

-- Tom

On 06/22/2012 12:29 AM, Charles Eckel (eckelcu) wrote:
>>>> server and receives a Status or an Error message back; the
>>>>          
>>> client runs
>>> T1 and
>>>        
>>>> retransmits the request if no response arrives in time, but
>>>>          
>>> the server
>>> does
>>>        
>>>> 2) Server-initiated: The server sends a notification (i.e.
>>>>          
>>> a follow-up
>>> status
>>>        
>>>> message) to the client and receives a StatusAck back. The
>>>>          
>>> server runs
>>> T1 and
>>>        
>>>> (Question: Can the client send an Error message instead of
>>>>          
>>> StatusAck?
>>> Error
>>>        
>>>> seems to be reserved for the direction server to client,
>>>>          
>>> but the draft
>>> is not
>>>        
>>>> 100% clear about that.)
>>>>
>>>> transaction-initiating request, with ErrorAck forming the
>>>>          
>>> response? If
>>> so,
>>>