Re: MSRP: Are REPORTs per-chunk or per-message? (was Re: [Simple]Review of draft-ietf-simple-message-sessions-08 - Byte Ranges inREPORTs)

[Cullen Jennings <fluffy at cisco.com>]

On 10/11/04 7:09 PM, "hisham.khartabil at nokia.com"
<hisham.khartabil at nokia.com> wrote:

> Cullen,
> 
> I apologise if you misunderstood my email. I did not intend to say that there
> is no requirement to support large messages. I was just questioning the
> requirement for the robustness of the recovery mechanism and exploring how the
> protocol would work with a weaker recovery mechanism. You clearly feel strong
> about such a requirement, so lets assume that it is a requirement for MSRP. I
> will not take up your proposal to kill the MSRP work immediately ;)


Sorry, I was just having an allergic reaction to reopening this mess.

I think people imagined roughly 3 different orders of magnitude of large.
I'll roughly describe these as

1) Larger than a MTU but less than a few kilobytes

2) Around a 10 K message - certainly something that takes considerable time
to transfer across some wireless links.

3) Around 100k over slow link of perhaps megabytes over fast link.

We agreed that we needed more than 1 and at least 2. Not sure if we ever
agreed on 3 or not but when we went to do 2, things got to more or less
where they are in the current MSRP document.


> 
> More comments inline...
> 
>> -----Original Message-----
>> From: ext Cullen Jennings [mailto:fluffy at cisco.com]
>> Sent: 11.October.2004 18:23
>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Paul H Kyzivat; Robert
>> Sparks
>> Cc: simple at ietf.org
>> Subject: Re: MSRP: Are REPORTs per-chunk or per-message? (was Re:
>> [Simple]Review of draft-ietf-simple-message-sessions-08 - Byte Ranges
>> inREPORTs)
>> 
>> 
>> Right now we have a fairly concrete proposal on the table to
>> make this work.
> 
> If we have a concerete proposal, then what is all the fuss about?

Perhaps the proposal is still lacking text to explain. Will keep working on
clarifying it. 

> 
>> It does use negative reports on byte ranges and uses positive
>> and negative
>> reports on complete messages. It does not need anything else
>> thought the
>> positive reports on byte ranges can allow the sender to
>> better understand
>> the status of a message and I suggest they be optionally
>> allowed but not
>> required.
> 
> As I stated earlier I see value in allowing all this.
> 
> 
>> 
>> Unless someone has a really good reason why the current
>> proposal does not
>> meet their needs, I would really rather not start over.
> 
> Neither would I.
> 
>> 
>> On 10/11/04 9:50 AM, "hisham.khartabil at nokia.com"
>> <hisham.khartabil at nokia.com> wrote:
>> 
>>> 
>>> Lets look at a scenario: Sender is sending a large message
>> and requests
>>> success report. If the receiver is to report byte-range
>> success, then the
>>> benefit is that the sender's implementation can determine
>> if there has been
>>> failure in delivering a byte range and re-send those.
>>> 
>> A sender figures out what needs to be resent using the
>> negative not positive
>> reports on a chunk.
> 
> It can also do so by checking which byte range it did not get positive reports
> for. This is the requirement question I had. I'll repeat it here: Do we want
> success reports to aid the user in  determining what happened to the message
> s/he sent, or the implementation in recovering from a lost byte range? I think
> we want the former.
>

I agree - I had imagined that if you did not get a positive REPORT for the
whole thing after some implementation defined time, you would notify the
user that the message had not worked. I can imagine that success reports on
a subset of the message might be used to update status but they would not
be used in deciding what needed to be retransmitted.
 
> 
>>> Again, I ask the question of requirements. Are the failure
>> reports meant for
>>> user consumption or for implementation to recover? I'm
>> inclined to say we want
>>> the former and therefore suggest that failure reports to be
>> per message. It is
>>> left as a user decision what to do if that failure report
>> is received.
>>> 
>> 
>> The current document has reports for failure of a chunk as meant for
>> retransmission purposes.
> 
> Ok, this is acceptable for me.
> 
>>  
>>> Remember, this is not a file transfer protocol. It is an
>> instant messaging
>>> protocol. If the message is large, it is chunked, but it is
>> still a message
>>> and success and failure reports should be per message. A
>> message is message,
>>> large or small.
>>> 
>> 
>> Exactly the opposite requirement was stated before. The
>> argument made before
>> was it I had just transferred 20k over my wireless link and
>> lost the last 1
>> k block, we did not want to resend the whole 20k. Adam and I
>> both pointed
>> out at that time that this was going to complicate stuff.
> 
> Ok , no need to argue further if this is a requirement or not.
> 
>>  
>>> Lets now look at Cullen's Elevator problem: Cullen is
>> sending Ben a large file
>>> using his IM client running on his mobile device. Cullen
>> walks into an
>>> elevator and looses radio service. When Cullen walks out of
>> the elevator, he
>>> expects his IM client to continue transmitting from where
>> it left off.
>>> 
>>> When Cullen walks into the elevator, any TCP connections
>> are lost and
>>> therefore Ben's IM client can't report the failure anyway.
>> Ben's client can
>>> only wait for x number of minutes hoping that Cullen's
>> client comes back
>>> online and re-establishes the session. Cullen's client does
>> not know the byte
>>> range that Ben's client has received and can therefore only
>> commence from
>>> where it has sent the last byte. Is that ok?
>>> 
>> 
>> no this would not be ok. The relay that was sending a chunk
>> to me when the
>> connection failed will report an error on that chunk (an any
>> others that it
>> is holding) and that data will get retransmitted.
> 
> How is it going to report an error when the connection it has with your device
> is lost?

This is the long thread that Adam, Orit, and I had about why the sender
needs to run a timer so that if the connection to the next hop is lost, an
error can still be reported back. Of course this adds extra load so we have
added the option of turning this on or off. If it is turned off, you won't
get the error and will only be able to use the lack of success report for
whole message after some time to deal with this.


> 
>>  
>>> If we continue to think that a message is a message, even
>> if spread across IM
>>> sessions, then Ben's client can report success or failure
>> of the message that
>>> was sent across both those sessions.
>>> 
>> 
>> In this case, Ben and I only had one IM session. It was just
>> that it used a
>> couple of MSRP sessions to transport the data in it.
> 
> Ok, whatever the terminology is: do you agree that a success of failure report
> for a message can be sent to a message that spanned more than 1 MSRP session?
> 

Yes

> Regards,
> Hisham
> 
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple



_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple