Re: Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)]

Thank you Saúl.

/Miguel

On 05/09/2012 16:46, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Sep 5, 2012, at 3:32 PM, Miguel A. Garcia wrote:
>
>> In relation with the issue of chunked messages, where the MSRP switch does not receive a last chunk due to, e.g., the sender's connection is dropped, I have a proposal and a doubt.
>>
>> Proposal:
>>
>> 	  Once the MSRP switch receives the last chunk of a message,
>> 	  and that chunk is successfully sent to each of the
>> 	  recipients, the MSRP switch MUST discard the temporary
>> 	  storage of MSRP Message-ID and the associated list of
>> 	  recipients.
>>
>>
>> 	  In some occasions, a sender might suffer a transport error
>> 	  condition (such as loss of connectivity) that makes the
>> 	  sending of a message incomplete, e.g., some chunks were
>> 	  received by the MSRP switch, but not all of them. This is a
>> 	  behavior already considered in the core MSRP specification
>> 	  (see <xref target="RFC4575"> RFC 4575 </xref> Section
>> 	  5.4). The problem in the context of a chat room lies with
>> 	  the usage of temporary storage for fast forwarding. In order
>> 	  to prevent attacks related to the exhaustion of temporary
>> 	  storage of chunked messages, on receiving a first chunk of a
>> 	  message, where the MSRP switch is using the fast forward
>> 	  method, the MSRP switch MUST set a timer for controlling the
>> 	  reception of the remaining chunks. This timer can be re-set
>> 	  every time a new chunk of the same message is received. When
>> 	  this timer fires, the MSRP switch MUST considered that the
>
> "the MSRP switch MUST consider that the"
>
>> 	  sending of the message was aborted, and MUST delete all the
>> 	  temporary storage pertaining to this message.
>>
>> Now the doubt. If the above condition happens, I would like to know what is best to do with respect the recipients. These are in a strange state, where they have received a number of chunks of a message, but not all the chunks, and they will not receive any more. What the MSRP switch can do:
>>
>> a) Nothing. The recipients have received a number of a chunks of a message; the message is not complete. The MSRP switch will send other messages (perhaps originated by other participants), but this chunked message will remain in the endpoints until the endpoint crashes^H^H^H^H^H^H^Hrecovers from that situation.
>>
>> b) A nice MSRP switch will create a new chunk, as it if were received from the sender, where there won't be any content, but just the abort flag "#". At least this one will have a bigger likelihood of endpoint recovery.
>>
>> I propose to do b). I guess there are no security issues, even if TLS is used, because the TLS connection is ending at the MSRP switch.
>>
>> Can anyone think of other options? Is option b) reasonable?
>>
>
> I agree with taking the b option approach, it's reasonable.
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain