From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Horvath, Ernst" <ernst.horvath@siemens-enterprise.com>,
 "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model
 behindError/ErrorAck?
Thread-Index: AQHNTrTiz/xmitc28EeHhoXKx6yXbZcFU0+Q
Date: Thu, 21 Jun 2012 22:29:08 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com>
References: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C0753D0C8@xmb-sjc-234.amer.cisco.com>
 <C2BCA7974025BD459349BED0D06E48BB016B03@MCHP03MSX.global-ad.net>
In-Reply-To: <C2BCA7974025BD459349BED0D06E48BB016B03@MCHP03MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model
 behindError/ErrorAck?
Precedence: list

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.=20
In RFC 4582, the Error message is always a response, as you correctly point=
ed out. As such, there is not a real need for an ErrorAck. This is similar =
to the FloorRelease/FloorRequestStatus exchange. In this case, a FloorReque=
stStatusAck is not necessary. Similarly, if a server responds to a client i=
nitiated transaction message with an Error, that should complete the transa=
ction 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 unsup=
ported BFCP version. You correctly point out that the usage of Error/ErrorA=
ck in these scenarios is underspecified. I'd like to propose that we restri=
ct this new usage as well to cases in which a server is responding to a cli=
ent initiated transaction. I believe this remains consistent with the spiri=
t of the Error message in RFC 4582 and removes the need for the ErrorAck.

Cheers,
Charles

> -----Original Message-----
> From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com]
> Sent: Wednesday, June 20, 2012 12:18 AM
> To: Charles Eckel (eckelcu); bfcpbis@ietf.org
> Subject: RE: [bfcpbis] RFC4582bis: What is the transaction model
> behindError/ErrorAck?
>=20
> Charles,
>=20
> Well, I did not find answers in the existing text to questions such as:
>=20
> - Is ErrorAck sent in reply to every Error message, or only in some cases=
?

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=20
   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.
> - Can Error create its own transaction, using a new transaction ID, e.g. =
if a
> datagram could not be parsed?
>=20
> I guess some additional text is needed to clarify the use of Error/ErrorA=
ck in
> general, and maybe some specific failure scenarios deserve their own
> description.
>=20
> Regards,
> Ernst
>=20
>=20
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> > Sent: Dienstag, 19. Juni 2012 20:58
> > To: Horvath, Ernst; bfcpbis@ietf.org
> > Subject: RE: [bfcpbis] RFC4582bis: What is the transaction
> > model behindError/ErrorAck?
> >
> > (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: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> > > Behalf Of Horvath, Ernst
> > > Sent: Friday, June 15, 2012 5:56 AM
> > > To: bfcpbis@ietf.org
> > > 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
> > > bfcpbis@ietf.org
> > > https://www.ietf.org/mailman/listinfo/bfcpbis
> >