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

Hi Ben:

Some inline comments.

On 05/09/2012 20:54, Ben Campbell wrote:
>
> On Sep 5, 2012, at 8:32 AM, Miguel A. Garcia
> <[email protected]> wrote:
>
>> 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.
>
> It's not limited to transport failures. For example, the sender could
> lose power before completing the message.

True, that is another example of loss of connectivity. I will add it.

>
>> 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.
>
> Seems like it would be even worse if you weren't doing fast
> forwarding. Then the switch would be saving the chunk contents for
> reassembly, wouldn't it?

Yeah, you hit a point that I was thinking yesterday when I was composing
the text. The need of a timer to detect incomplete messages (due to chunk
messaging) is not restricted to the fast forwarding mechanism, but it is
also applicable when the non-fast forwarding mechanism is used.

Let's keep this in mind. First I want to get the text correct and
complete focusing on the fast forwarding mechanism. Then we will need to
extrapolate it to the non-fast forwarding mechanism.


>
>> 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?
>>
>
> Repeating a comment from a separate thread:
>
> 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.

Totally agreed. I will work to reflect this in the draft.

/Miguel


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

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