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

From: [email-masked]
Date: Mon, 11 Oct 2004 20:09:35 +0300

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 ;)

More comments inline...

> -----Original Message-----
> From: ext Cullen Jennings [mailto:[email-masked]]
> Sent: 11.October.2004 18:23
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Paul H Kyzivat; Robert
> Sparks
> Cc: [email-masked]
> 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?

> 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, "[email-masked]"
> <[email-masked]> 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.

> > 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?

>  
> > 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?

Regards,
Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Oct 2004 10:40:33 +0200

On 10/11/04 7:09 PM, "[email-masked]"
<[email-masked]> 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.

> 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 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.
 
> How is it going to report an error when the connection it has with your device

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.

> 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

---

From: "Peter Ridler" <[email-masked]>
Date: Tue, 12 Oct 2004 11:06:50 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Tuesday, October 12, 2004 4:41 AM
To: [email-masked]; Paul H Kyzivat; [email-masked]
Cc: [email-masked]
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, "[email-masked]"
<[email-masked]> 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 ;)

>> Right now we have a fairly concrete proposal on the table to make 
>> this work.
> 

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

>> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2004 13:18:37 -0400

> size negotiated at call setup time (maybe in the SDP of the SIP INVITE!!).

You can do that.

But some people believe that IM sessions are often expected to provide 
file transfer capabilities, and that this protocol must tolerate that to 
be competitive.

> to make sure any relay's did not loose a chunk somehow. 

You can do that too. (Its optional because some people didn't want it.)

 > Also, maybe just
> communicate in (like RTP is for voice, MSRP would be for text).

Yep. That is all stuff we are after.

 > My concern

This is just the normal division of responsibility thing. It isn't any 
different than RTP, which can be used with SIP, but isn't restricted to SIP.

We haven't included anything that we didn't think was needed for use 
with SIP, and I have heard of nobody who is actually planning to use it 
without SIP.

> conversation. 

I don't think we have a requirement here any stronger than that for sip 
voice. But I do  think that as time goes on the requirements will be 
there for more robustness in general. In the elevator case with a sip 
voice call, it is the RTP stream that will probably notice there is a 
problem. At that time the endpoint(s) can decide to drop the call, or 
they can attempt to reinvite in order to test the signaling channel, and 
perhaps reestablish a voice link if the signaling still works.

In the elevator case, the signaling probably wouldn't work, so the call 
would drop.

The case we have been more concerned with is when an intermediary to the 
call fails, in particular a MSRP relay that is being used to get through 
a firewall and/or to log the conversation, etc. In that case the sip 
path will still work, so it becomes possible to reestablish the media 
stream and continue.

 > You need to redial to start the session over again.  Asking a

Depends on what is disconnected. If just the media, it may be 
reasonable. We do realize that there will be different levels of 
sophistication in the implementations of MSRP. Simple ones may not 
recover, while more sophisticated ones might. Some people won't care, 
while those that do will choose implementations that meet their 
expectations.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Oct 2004 20:42:38 -0500

On Oct 12, 2004, at 12:18 PM, Paul Kyzivat wrote:

[...]

> with SIP, and I have heard of nobody who is actually planning to use 
> it without SIP.

Just to emphasize this point--the next revision will contain language 
stating that MSRP MUST NOT be used as a stand-alone protocol. It MUST 
be used with some control protocol, such as SIP, that supports the SDP 
offer-answer model.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Oct 2004 21:50:46 -0500

Wow, the quotes have gotten long here--will attempt some surgery...	
(inline)

On Oct 12, 2004, at 3:40 AM, Cullen Jennings wrote:

[...]

> where they are in the current MSRP document.

I think the difference between 2 and 3 is, do we want it to be possible 
to recover from a failed message by sending a subset of the original 
message.

[...]

> Perhaps the proposal is still lacking text to explain. Will keep 

There has _not_ so far been a concrete proposal that explicitly states 
whether reports are per-chunk or per-message. The latest draft revision 
_implies_ per chunk, as it includes a byte-range, and we say that a 
sender is allowed to split the chunks of a message between one session 
and another in a failover condition.

But, I think people are assuming a lot more complexity than necessary. 
I think it comes down to saying something to the effect of, if a report 
includes a byte-range, then it refers to the subset matching those 
bytes. If not, it refers to the entire message. The sender is free to 
take any action it likes on that knowledge, including ignoring it. 
Remember, we are not _requiring_ retransmission of failed messages.

As I mentioned in a previous email, I think that sending failure 
reports per-message will cause quite a bit of complexity at relays, and 
require them to keep state around for failed messages.

After giving this some thought, I think the behavior is likely to 
differ between endpoints and relays. For the reason I mention above, I 
think relays should send failure reports on a per-chunk basis.

Relays don't send success reports, so we don't have to worry about that 
combination.

On the other hand, endpoints will rarely send failure reports, and if 
they do, it will be because of some sort of whole message error. I 
offer the sending of a failure report with a 415 status as an example; 
the whole message has failed and resending is not likely to help. 
Therefore, any failure reports sent by an endpoint should be 
per-message.

I see that there _can_ be some use for byte-ranges in success reports. 
As Hisham mentioned,  if the endpoint receives a partial message, but 
some timeout occurs before the rest is received, then it could send a 
success report on the bytes actually received. But I now convinced this 
creates more complexity than value.

So, a concrete proposal:

Relays that send a failure report because they are unable to forward a 
chunk to the next hop due to a transport error, or because they receive 
a failure response from the next hop for that chunk, SHOULD copy the 
byte-range header value from the chunk to the failure report.

Endpoints sending a success or failure report SHOULD NOT include a 
byte-range header.

Endpoints that receive a report containing a byte-range header MUST 
assume the report only covers the bytes listed. If no byte-range header 
is present, or if the range is ambiguous , the endpoint MUST assume the 
report covers the entire message. How an endpoint uses this information 
is a matter of local policy.

[...]

> be used in deciding what needed to be retransmitted.

Assuming, of course, that positive reports were requested in the first 
place.

>> Ok, this is acceptable for me.

I _think_ my proposal above agrees with this statement.

[...]