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

In relation with the issue of chunked messages, where the MSRP switch 
does not receive a last chunk due to, e.g., the sender's connection is 
dropped, I have a proposal and a doubt.

Proposal:

	  Once the MSRP switch receives the last chunk of a message,
	  and that chunk is successfully sent to each of the
	  recipients, the MSRP switch MUST discard the temporary
	  storage of MSRP Message-ID and the associated list of
	  recipients.


	  In some occasions, a sender might suffer a transport error
	  condition (such as loss of connectivity) that makes the
	  sending of a message incomplete, e.g., some chunks were
	  received by the MSRP switch, but not all of them. This is a
	  behavior already considered in the core MSRP specification
	  (see <xref target="RFC4575"> RFC 4575 </xref> Section
	  5.4). The problem in the context of a chat room lies with
	  the usage of temporary storage for fast forwarding. In order
	  to prevent attacks related to the exhaustion of temporary
	  storage of chunked messages, on receiving a first chunk of a
	  message, where the MSRP switch is using the fast forward
	  method, the MSRP switch MUST set a timer for controlling the
	  reception of the remaining chunks. This timer can be re-set
	  every time a new chunk of the same message is received. When
	  this timer fires, the MSRP switch MUST considered that the
	  sending of the message was aborted, and MUST delete all the
	  temporary storage pertaining to this message.

Now the doubt. If the above condition happens, I would like to know what 
is best to do with respect the recipients. These are in a strange state, 
where they have received a number of chunks of a message, but not all the 
chunks, and they will not receive any more. What the MSRP switch can do:

a) Nothing. The recipients have received a number of a chunks of a 
message; the message is not complete. The MSRP switch will send other 
messages (perhaps originated by other participants), but this chunked 
message will remain in the endpoints until the endpoint 
crashes^H^H^H^H^H^H^Hrecovers from that situation.

b) A nice MSRP switch will create a new chunk, as it if were received 
from the sender, where there won't be any content, but just the abort 
flag "#". At least this one will have a bigger likelihood of endpoint 
recovery.

I propose to do b). I guess there are no security issues, even if TLS is 
used, because the TLS connection is ending at the MSRP switch.

Can anyone think of other options? Is option b) reasonable?

/Miguel


On 05/09/2012 9:19, Miguel A. Garcia wrote:
> In my previous e-mail, please s/5.3/5.4
>
> To be explicit: the MSRP Connection Model is described in Section 5.4 of
> RFC 4975.
>
> /Miguel
>
> On 05/09/2012 9:15, Miguel A. Garcia wrote:
>> Hi Ben,
>>
>> Thanks for your comments
>>
>> On 04/09/2012 16:26, Ben Campbell wrote:
>>> (As individual)
>>>
>>> Hi,
>>>
>>> I agree with Miguel's responses except as noted inline
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia"
>>> <[email protected]> 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.
>>>
>>> The "how long to wait for a chunk" problem is no different than for
>>> any other endpoint, is it, other than possibly differences of scale? I
>>> suggest we refer back to 4975 for this, with the possible note to the
>>> effect of "This is no different than for any MSRP endpoint that
>>> receives a chunked message. However, since a conference switch will
>>> typically participate many sessions at one time, storage management
>>> may be more critical"
>>
>>
>> I would like to include a reference to the section in RFC 4975 that
>> discusses this topic. I guess it is Section 5.3, when it discusses what
>> happens if a transport connection fails.
>>
>>>
>>>>>
>>>>> 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.
>>>
>>> Keep in mind there could be an MSRP relay between the sender and the
>>> switch, so the transport connection may not be direct. But again, this
>>> is no different than for any other MSRP endpoint.
>>
>> Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975.
>>
>>>
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> Section 6.1 (trivial nit)
>>>>>
>>>>> The SEND request MUST contain a top-level wrapper of type
>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862].  The actual
>>>>> instant message payload MUST be included as payload of the
>>>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the
>>>>> SDP 'accept-types' attribute according to the MSRP rules.
>>>>>
>>>>> I think s/MAY/may/. That is, a type must be set, and the type must
>>>>> be only one of those that has been negotiated.
>>>>>
>>>>>
>>>>
>>>> I think this MAY should actually be a MUST, because as you said, a
>>>> types must be said, and this type cannot be anyone, but it MUST be
>>>> one of those negotiated.
>>>
>>> This is already mandated in RFC4975 (as you go on to say...). The only
>>> thing new is the normative requirement for a particular wrapper type.
>>> It might be worth commenting that this is accomplished by putting only
>>> Message/CPIM in accept-types, and all allowed leaf types in
>>> accept-wrapped-types.
>>
>> Ok, we can clarify it. Actually, we do not mention what can go in an
>> accept-wrapped-types, because it was obvious that any type can go in. But
>> it might be worth adding some explicit mention to it.
>>
>>>
>>>>
>>>> I like the "according to the MSRP rules", as a mechanism to indicate
>>>> that we are not mandating something new, but just copying what MSRP
>>>> mandates.
>>>>
>>>
>>> ... in which case it should be stated descriptively, not normatively.
>>
>> Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I
>> think the text ought to say: "According to RFC 4975, the endpoint needs
>> to  ...". This is makes it clear, and we do not over-specify.
>>
>> /Miguel
>>
>

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