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

On Sep 4, 2012, at 10:29 AM, Paul Kyzivat <[email protected]> wrote:

> On 9/4/12 9:35 AM, Miguel A. Garcia wrote:
> 
>>> Section 6.1
>>> 
>>>    An MSRP
>>>    switch that uses this fast forwarding procedure MUST temporarily
>>>    store the Message-Id of the MSRP message to correlate the different
>>>    chunks, as well as it MUST temporarily store the list of recipients
>>>    to which the initial chunks were delivered.
>>> 
>>> The motivaiton is clear. I think you could add that the storage can be
>>> released when the last chunk is seen. But what happens when the last
>>> chunk is not seen (or delayed)? How temporary is the storage, and how is
>>> it released?
>> 
>> Yes, we can add that the temporary storage is released when the last
>> chunk is seen or after a reasonable time passes.
>>> 
>>> Or do we assume that because MSRP uses TCP (or similar) that loss will
>>> always be accompanied by connection failure and so that is the only
>>> trigger needed to abandon temporary storage?
>> 
>> Yes, on one side, the assumption is that if a last chunk is not seen is
>> because there has been a transport failure. Since TCP is used, then the
>> TCP connection was broken, and is in the process of being re-established.
>> I am more concerned about what happens if the last chunk is not seen at
>> all, I am not sure the state the MSRP session will be, even if the
>> connection is re-established.
> 
> 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.

That's a good point. While a connection failure ends the "session", the endpoints can attempt to reestablish a new session and send the remaining chunks over it. So I concur the best we can offer is to wait a "reasonable time". I can see "reasonable" being different for a high-volume switch than for an end-user endpoint.

> 
> 	Thanks,
> 	Paul
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple