Subject: Re: [Simple] MSRP: Surpression of duplicates

From: Cullen Jennings <[email-masked]>
Date: Thu, 01 Jul 2004 10:40:30 -0700

Sounds good to me - more inline

On 6/30/04 6:41 AM, "Ben Campbell" <[email-masked]> wrote:

>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]]On Behalf
>>>> Of ext Ben Campbell
>>>> Sent: 28.June.2004 23:36
>>>> To: Simple WG
>>>> Subject: [Simple] MSRP: Surpression of duplicates
>>>> 
>>>> 
>>>> The working group has gone round and round on whether (and how) we
>>>> handle worry about the surpression of duplicate messages, in
>>>> situations 
>>>> where a failure occurs, and the sender chooses to re-send
>>>> content on a 
>>>> new session.
>>>> 
>>>> Since we have introduced the concept of a MessageID, this
>>>> becomes fairly
>>>> easy to accomplish. If we specify the MessageID to be
>>>> globally unique,
>>>> or even just very likely to re-occur in a relatively short
>>>> time period, 
>>>> then the receive can simply watch for duplicate messageIDs. The
>>>> receiver's action upon receiving a duplicate would be entirely up to
>>>> local policy (although simply displaying the duplicate to the user
>>>> without any warning of duplication would be a bad choice.)
>>>> 
>>>> This approach only works for detecting whole-content
>>>> duplication, rather
>>>> than chunk duplication. We recommend that chunks of a given
>>>> message not 
>>>> be spread across more than one session.
>>> 
>>> I don't like this recommendation. If I'm sending you a 5GB file in chunks
>>> and
>>> the session breaks, then I would like to continue where I left off. But I
>>> guess it doesn't necessarily have to be the same message ID.
>> 
>> 
>> I got lost on this - I think I agree with Hisham - I think the mechanims
>> does work for chunk duplicate - you find a message using the messageId and
>> if you already have data for the range of data in the chunk, you can ignore
>> the part that is an overlap. Perhaps that is what you say in the next
>> paragraph
> 
> Yes. I meant to say that, the message ID plus the byterange information
> is sufficient to detect chunk duplication or overlap, so we don't need
> some special chunk ID.
> 

Yep - makes sense. 

> I believe Hisham was objecting to the recommendation not to spread
> chunks of the same message accross sessions. I will back away from that
> a bit and say you shouldn't do it under normal conditions, but it may be
> acceptable for recovering from a failed session.

Fine with me. 

I think the thing we need to be clear on in the messasgeID needs to be
unique across all the session on a single endpoint. I don't care if two
different endpoint end up with a sending a message with the same message ID.
Do other see issue with this?

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 01 Jul 2004 12:45:33 -0500

> Do other see issue with this?

Makes sense to me.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Jul 2004 16:23:03 -0400

> Do other see issue with this?

I'm not sure "single endpoint" quite captures the requirement, but I 
agree we don't need global uniqueness.

What we need is uniqueness across a media streamand all its possible 
successor streams- assuming we can define what constitutes a successor 
stream. I think that means a stream initially established via an 
offer/answer and associated with a particular m-line position in the 
offer/answer, plus additional streams established by changes to that 
m-line and its attributes. That is a pretty clumsy definition, but I 
can't come up with a simpler one offhand.

	Paul