Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Overlapping Chunks

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Oct 2004 17:40:02 -0500

On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote:

> Section 6.3.1 discusses how to handle the receipt of overlapping 
> chunks,
> specifying that the last received copy of any particular byte wins. I
> don't think this is good.
>
> If the overlapping chunks contain consistent data then it doesn't 
> matter
> which takes precedence. If they contain conflicting data then 
> reordering
> of chunks can affect the result unpredictably. This rule also prevents
> the recipient from rendering a byte when it and all preceding bytes 
> have
> been received.
>
> I think it should be permissible for the recipient to check for
> inconsistency in the overlapping case, and report an error if so. We 
> may
> want to require this checking. (Since it typically won't happen it
> shouldn't have a performance impact.)
>

I'm not sure on this one. As far as typically not happening, I can 
imagine situations where a chunk gets an error report, but still got 
delivered. The sender might send a new chunk with that range.

Perhaps it would be better to say that, if a sender does this, it MUST 
NOT change the data in the range.

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Oct 2004 10:41:56 -0400

Ben Campbell wrote:
>> Section 6.3.1 discusses how to handle the receipt of overlapping chunks,
>> If the overlapping chunks contain consistent data then it doesn't matter
>> which takes precedence. If they contain conflicting data then reordering
>> the recipient from rendering a byte when it and all preceding bytes have
>> been received.
>>
>> inconsistency in the overlapping case, and report an error if so. We may

I'm having trouble with this scenario, given that we have a reliable 
transport protocol.

The most obvious case that comes to mind for me is loss of the TCP
connection. The recovery action in that case is to resignal to establish 
a replacement connection and then retransmit any chunks that hadn't been 
confirmed.

> NOT change the data in the range.

Yes, I think that would be a good thing to do. And a recipient that 
recives overlapping data MAY report an error if inconsistent overlapping 
data is received. (Do we have a suitable error for that?)

	Paul