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!!).
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).
--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