Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)

On 9/4/12 9:35 AM, Miguel A. Garcia wrote:

>> Section 6.1
>>
>>     An MSRP
>>     switch that uses this fast forwarding procedure MUST temporarily
>>     store the Message-Id of the MSRP message to correlate the different
>>     chunks, as well as it MUST temporarily store the list of recipients
>>     to which the initial chunks were delivered.
>>
>> The motivaiton is clear. I think you could add that the storage can be
>> released when the last chunk is seen. But what happens when the last
>> chunk is not seen (or delayed)? How temporary is the storage, and how is
>> it released?
>
> Yes, we can add that the temporary storage is released when the last
> chunk is seen or after a reasonable time passes.
>>
>> Or do we assume that because MSRP uses TCP (or similar) that loss will
>> always be accompanied by connection failure and so that is the only
>> trigger needed to abandon temporary storage?
>
> Yes, on one side, the assumption is that if a last chunk is not seen is
> because there has been a transport failure. Since TCP is used, then the
> TCP connection was broken, and is in the process of being re-established.
> I am more concerned about what happens if the last chunk is not seen at
> all, I am not sure the state the MSRP session will be, even if the
> connection is re-established.

Because a failed TCP connection may be reestablished, and the chunk sent 
over the new connection, you can't use connection loss as a trigger for 
giving up on incomplete chunked messages.

The receiver has no firm way to distinguish between a chunk that has 
been a chunk that has been lost and one that has simply been delayed. 
This has to be dealt with via implementation policies and heuristics.

	Thanks,
	Paul