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

[Ben Campbell <ben at nostrum.com>]

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

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

[...]

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

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.


[...]

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

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.

[...]

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

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

> > > The current document has reports for failure of a chunk as meant for
> > > retransmission purposes.
> >
> > Ok, this is acceptable for me.

I _think_ my proposal above agrees with this statement.

[...]


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