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

A couple of comments below.

On 05/09/2012 18:10, Ben Campbell wrote:
>
> 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 only way for the MSRP switch to detect this failure is through a timer.

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

The final recipients should be already be able to deal with missing 
chunks with regular MSRP (outside the chat context). An endpoint might be 
receiving MSRP chunks through a relay. The sender's connection with the 
relay goes down; the recipient should be able to deal with this case.

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

Sounds reasonable.

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

Yeah, provoking an abort seems to be an optimization that the MSRP switch 
will do to the endpoints. Somehow I am leaning towards adding a "MAY" 
send an abort if this condition is detected.

/Miguel


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

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain