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

On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" <[email protected]> wrote:

> Thank you Paul,
> 
> I think you are right, under failure circumstances chunks might be sent over different MSRP sessions, if a new session is re-established.
> 
> So, I believe the only mechanism we have for a permanent deletion of a partially received message is set a timer.
> 
> In a chat room environment, this means that when this type of failure occurs, the MSRP switch might have sent a number of chunks to the rest of the participants, leaving the total message incomplete at those endpoints. I wonder if the MSRP switch should, in this case, create an abort chunk ("#" flag) to avoid that the rest of the endpoints remain in a strange state. I think so.

I agree.

> 
> /Miguel
> 
> 
> On 04/09/2012 17:29, Paul Kyzivat wrote:
>> 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.
>> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain