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

On Sep 5, 2012, at 9:43 AM, Paul Kyzivat <[email protected]> wrote:

> On 9/5/12 9:49 AM, Ben Campbell wrote:
>> 
>> 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.
> 
> Will the MSRP switch necessarily *know* that this failure has occurred?
> 
> The switch is not obligated to receive the complete message before forwarding. It needs to remember incomplete messages, but need not consume buffer space for them. So it may tolerate an incomplete message for a long time.
> 
> *If* it decides to give up on a message with a missing chunk then I agree that it makes sense for it to tell the downstream recipients as suggested. But they had better not *depend* on this.

Agreed. The final recipients must be able to deal with missing chunks, regardless of what the switch does. On reflection, it doesn't seem like the switch has to keep all that much state if it's doing fast forwarding, i.e. it doesn't to store chunks for reassembly like the final recipient does. So I'd almost see this is a "MAY discard the message-id after some reasonable period of time, based on local policy."

I first thought we needed the abort chunk--but it's really just an optimization. I wonder if it's worth it to introduce a need to originate content. Are there situations where it could do harm? S/MIME signed content might be one, but I guess if all the chunks don't make it, the signature is toast anyway.


> 
> 	Thanks,
> 	Paul
> 
>>> 
>>> /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
>> 
>> 
>