Subject: RE: [Simple] MSRP message reliability(long)

From: "Orit Levin" <[email-masked]>
Date: Fri, 9 Apr 2004 00:03:06 -0700

Ben,
I am replying to this and some of the points from your following mail
together.

[...]

First, I would like to clarify the reliability requirements, as I see 
them, a little. As I see it, when I send a message, there are three 
levels of reliability that I might care about. Consider the following 
scenarios:

1) I really don't care at all. (Strangely, this is the mode used by a 
lot of existing large scale systems. If we are dealing with highly 
interactive conversations between humans, humans provide their own 
reliability mechanism. I find myself typing "Hey, did you get my IM 
about X a few minutes ago" frequently.)

2) I want a good effort to deliver, and a good attempt to tell me if 
something went wrong. If I hear nothing, I assume it most likely worked.

3) Delivery is critical. I want to be told that it worked, and if I 
don't hear anything, I assume it most likely failed.

My personal opinion is that 1 is generally unacceptable (dispite current

systems), 3 should be an option, but 2 will be the primary use case, and

the one we should optimize for. The rest of this email takes that 
perspective; if consensus proves me wrong then my analysis will change.

OL:

My opinion on 1 is very different from yours: we will not educate the
existing and prosperous industry what it means "acceptable" vs.
"unacceptable" service by defining a rigid protocol. The industry will
just not use such a protocol at all. The only way to define an IM
protocol that will link the IM islands together is to make it appealing
to the industry and having the ability to upgrade the service (to better
quality) without replacing all the end applications. Therefore, in my
view, 1 is MUST.

Also, I am not sure at all that most of the applications will use 2.
Those applications that will prefer to use 1 for majority of the user
messages, in parallel will use 3 with a DSN receipt for application
level keep-alive mechanism potentially per MSRP session.

Why are you opposing to a flexible hop-by-hop mechanism (in addition to
DSN)? It doesn't necessarily require negotiation - only local policy for
setting the bit.
Let's assume for a moment that a bit per message exists saying
"response/don't response" to the previous hop.

This is how I can imagine the defined interface:

Primitive "Send and Forget": This is #1 - the bit is set to FALSE
Primitive "Send with no DSN": This is #2 - the bit can be either TRUE or
FALSE
Primitive "Send with DSN on Error only": This may be redundant - the bit
can be either TRUE or FALSE
Primitive "Send with DSN on success": This is #3 (application receipt) -
the bit can be either TRUE or FALSE

Orit.

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 09 Apr 2004 09:15:02 -0500

Orit Levin wrote:

[...]
> "response/don't response" to the previous hop.

I oppose the ability to select whether you use transaction responses or 
not because it adds a huge amount of complexity to the protocol and any 
implementations. Adding or removing transaction responses _completely_ 
changes the protocol semantics. In effect, it would be saying we have 
two different required protocols with the same syntax on top. If we make 
this selectable, we make every implementer build 2 protocols with 
different state machines, etc. I think that will be _much_ more of an 
impediment to acceptance than performance differences in the range you 
predict.

My point is, if the working group were to decide we need to be able to 
run without transaction responses (a big if) , then we should _always_ 
run without transaction responses. As it is, earlier attempts at a 
message sessions did not have the transaction response, and the working 
group decided to put them it. (Does anyone remember the specific 
argument used at that time?)

But, on all of these points, working group consensus trumps either of 
our opinions. Please, anyone who cares one way or another, state your 
opinion asap!

---

From: Ben Campbell <[email-masked]>
Date: Fri, 09 Apr 2004 09:15:02 -0500

Orit Levin wrote:

[...]

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 9 Apr 2004 20:00:51 +0530

Also as discussed earlier in this forum, this adds a lot of traffic to
the client (specially the wireless mobile clients where the bandwidth is
an issue). If the workgroup plans to make it configurable to set the
delivery response for positive case off, then it has to be terminated
earlier than reaching the wireless medium. E.g. terminate the positive
response at the IM server in case the client has chosen not to receive
the positive acknowledgements of delivery of IM. 

If we fail to do this, imagine for every message I'm sending, there is
some traffic I'm getting back to my mobile device (which is painful
because i may be paying by the amount of traffic i transact from my
device). So although it becomes transparent to me from device, by i
still pay for it. The workgroup needs to consider this matter. I somehow
still prefer - "No news is good news".

Would be good to know more thoughts on this.

Regards,
Vikas Tandon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: vendredi 9 avril 2004 19:45
To: Orit Levin
Cc: Simple WG
Subject: Re: [Simple] MSRP message reliability(long)

Orit Levin wrote:

[...]
> Why are you opposing to a flexible hop-by-hop mechanism (in addition 
> to DSN)? It doesn't necessarily require negotiation - only local 
> policy for setting the bit. Let's assume for a moment that a bit per 
> message exists saying "response/don't response" to the previous hop.

---

From: "Vikas Tandon" <[email-masked]>
Date: Fri, 9 Apr 2004 20:00:51 +0530

Regards,
Vikas Tandon

-----Original Message-----

Orit Levin wrote:

[...]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 09 Apr 2004 09:39:55 -0500

> the positive acknowledgements of delivery of IM. 

Hi, could you clarify what "this" refers to in the previous paragraph? 
Keep in mind that we are really discussion two things: the transaction 
responses between hops, and the sending of delivery reports. It sounds 
to me like you are talking delivery reports, but I am not certain.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 09 Apr 2004 09:39:55 -0500

---

From: "Vikas Tandon" <[email-masked]>
Date: Sat, 10 Apr 2004 11:16:47 +0530

Hi Ben & Group,
By "this" i mean the earlier messages exchanged between me, Mr. Vijay
Gurbani, Mr. Hisham  and a couple of more participants. Yes i am
referring to the delivery reports.   
Regards,
-Vikas

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: vendredi 9 avril 2004 20:10
To: Vikas Tandon
Cc: 'Orit Levin'; 'Simple WG'
Subject: Re: [Simple] MSRP message reliability(long)

> the client (specially the wireless mobile clients where the bandwidth 
> is an issue). If the workgroup plans to make it configurable to set 
> the delivery response for positive case off, then it has to be 
> terminated earlier than reaching the wireless medium. E.g. terminate 
> the positive response at the IM server in case the client has chosen 
> not to receive the positive acknowledgements of delivery of IM.

> still pay for it. The workgroup needs to consider this matter. I 
> somehow still prefer - "No news is good news".
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ben Campbell

---

From: "Vikas Tandon" <[email-masked]>
Date: Sat, 10 Apr 2004 11:16:47 +0530

Hi Ben & Group,