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

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