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

I just went back and checked the draft text again, and conclude that my 
comment didn't make much sense. I was thinking the concern was with 
message buffer space. I see now that it was only concerned with 
buffering the message id and list of recipients. This is likely to be a 
low burden, so the server might be willing to buffer a lot of this sort 
of state. But it will still eventually need to give up on it. And the 
proposal is valid when it does give up.

	Thanks,
	Paul

On 9/5/12 10:43 AM, Paul Kyzivat 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.
>
>      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
>>
>>
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>