Re: Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)]

On 9/5/12 1:54 PM, Ben Campbell wrote:
> On reflection, I'm not sure we need to be aggressive with the normative language here. The receiving endpoints already have to be able to deal with missing chunks. We are talking about optimizations here, not interop-critical behavior. I would lean towards making it clear that a switch doesn't have to keep the message-id and recipients around forever, and allow it to send a cancelation chunk if it wants to, but not require it. Specifically, something to the effect of the following:
>
> 1) The switch MAY discard the message state if it receives no chunks within some reasonable time. The specific timeout value is a matter of local policy, but SHOULD NOT be too short. For example, a time interval on the order of a normal TCP timeout (i.e. around 9 minutes)  would be reasonable. A timeout on the order of a few seconds would not.
>
> 2) If a timeout occurs, or some other error occurs that prevents all chunks from arriving at the switch, the switch MAY choose to send a cancelation chunk. This is an optimization, since MSRP endpoints need to be able to handle incomplete messages anyway.

I agree with this suggestion.

I think making #2 optional makes sense, since it alleviates any of 
Miguel's concerns that sending the cancellation chunk might constitute 
an undue burden on the switch, while leaving open the ability of the 
switch to indicate that no further chunks will be arriving in a message.

I also think leaving the exact implementation details of #1 at the 
discretion of the switch makes sense. For example -- it might be 
perfectly fine for the switch to keep the state around for as long as 
the session exists, possibly removing state bindings on a LRU-basis (so 
as to avoid excessive state utilization). For some architectures, this 
might make more sense than running strict timers.

I also like the suggestion that any such state needs to stay around for 
at least as long as TCP retransmits information. It guarantees that the 
relay won't needlessly prevent delivery of a message by giving the 
underlying transport time to do everything it can.

/a