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

Tom Kristensen <tomkrist@cisco.com> Fri, 22 June 2012 13:18 UTC

Return-Path: <tomkrist@cisco.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 719E121F85D3 for <bfcpbis@ietfa.amsl.com>; Fri, 22 Jun 2012 06:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 B+8bs6I6s30T for <bfcpbis@ietfa.amsl.com>; Fri, 22 Jun 2012 06:18:29 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9021F8592 for <bfcpbis@ietf.org>; Fri, 22 Jun 2012 06:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=7857; q=dns/txt; s=iport; t=1340371109; x=1341580709; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SdY97OqPKrGssCu10mRMzK/elk2EiP6Sh+yJxdMUdSc=; b=UgtNxYy1kzSDmf91CKgpVOL9+Dkv1kAQxnynIaRAvLj2Cpo5ha9NQQMz 4JS0LwTJh+chRDhoXUJ7nQV/cgQ8FDu+TxiIKuQPWjQZx0iqmnN/ZHfek 0w266NXLWh2ctTaRw19fhWlTz3afrTQ3B5rFV8cVZnlK6+L0Xdlw/0bzk I=;
X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="6112107"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 22 Jun 2012 13:18:28 +0000
Received: from [10.55.88.51] (dhcp-10-55-88-51.cisco.com [10.55.88.51]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MDIRAI020346; Fri, 22 Jun 2012 13:18:27 GMT
Message-ID: <4FE470A3.8020506@cisco.com>
Date: Fri, 22 Jun 2012 15:18:27 +0200
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
References: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C0753D0C8@xmb-sjc-234.amer.cisco.com> <C2BCA7974025BD459349BED0D06E48BB016B03@MCHP03MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Horvath, Ernst" <ernst.horvath@siemens-enterprise.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
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: Fri, 22 Jun 2012 13:18:30 -0000

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:
> 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
>
>    
>> -----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?
>>
>> 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?
>>      
> 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.
>> - 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
>>>>          
>>>        
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>