[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MSRP: Are REPORTs per-chunk or per-message? (was Re:[Simple]Review of draft-ietf-simple-message-sessions-08 - Byte RangesinREPORTs)
Hi All,
I have seen a lot of messages flying back and fourth on this for some time
now. I am a new comer to the Simple group and do not know the total history
of this topic as of yet and have kept my head down for that reason.
However, I do see some things that may effect our application and would like
to state my 10 cents worth.
First of all I will use small messages (1-2K) so chunking is not a real
issue to me. I would like to be able to turn it on/off or maybe have the
size negotiated at call setup time (maybe in the SDP of the SIP INVITE!!).
When chunking does occur I believe a End-To-End acknowledgment is required
to make sure any relay's did not loose a chunk somehow. Also, maybe just
the relay to relay need to do a message (chunk) acknowledgment between
themselves and not include the Endpoint UA.
I became interested in MSRP because I thought it was a session message
system. The session that I believe that is in control is SIP. I need to be
able to tell if my destination Endpoint is available and will accept the
message session (just like a phone call). I also need to be able to
transfer the session to different Endpoints or to place the session on hold
(just like a phone call). I saw that SIP would take care of all the session
things and that MSRP was another media format the Endpoints could
communicate in (like RTP is for voice, MSRP would be for text). My concern
here is that it is becoming a stand alone system that just might work with
SIP.
One example I have seen that concerns me is the elevator case.... As far as
I'm concerned, if the session has dropped, all transfers are broken
(discarded) and a new SIP Session would need to be established before the
file transfer (large message) could begin again....just like if you are on
your cell phone, the elevator door closes, the call drops and so does your
conversation. You need to redial to start the session over again. Asking a
Endpoint UA to maintain state for a disconnected call does not make sense to
me.
--Peter
-----Original Message-----
From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf Of
Cullen Jennings
Sent: Tuesday, October 12, 2004 4:41 AM
To: hisham.khartabil at nokia.com; Paul H Kyzivat; rjsparks at nostrum.com
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
RangesinREPORTs)
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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple