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

"Horvath, Ernst" <ernst.horvath@siemens-enterprise.com> Wed, 20 June 2012 07:18 UTC

Return-Path: <ernst.horvath@siemens-enterprise.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA1F21F8704 for <bfcpbis@ietfa.amsl.com>; Wed, 20 Jun 2012 00:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQbdotWKTMae for <bfcpbis@ietfa.amsl.com>; Wed, 20 Jun 2012 00:18:27 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0821F8703 for <bfcpbis@ietf.org>; Wed, 20 Jun 2012 00:18:27 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3629D23F058C; Wed, 20 Jun 2012 09:18:24 +0200 (CEST)
Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 20 Jun 2012 09:18:23 +0200
From: "Horvath, Ernst" <ernst.horvath@siemens-enterprise.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck?
Thread-Index: Ac1OTX9TZCpfQ9MxRY+b6QQ9g+KingAYw6Ug
Date: Wed, 20 Jun 2012 07:18:22 +0000
Message-ID: <C2BCA7974025BD459349BED0D06E48BB016B03@MCHP03MSX.global-ad.net>
References: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C0753D0C8@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C0753D0C8@xmb-sjc-234.amer.cisco.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.26.0.183]
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?
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2012 07:18:28 -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


> -----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
>