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

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

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

I agree with the comment you just withdrew :-)

> 	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
>> 
> 
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple