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

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.

	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
>
>