Subject: Re: [Simple] Details on MSRP Details (DSN)

From: Aki Niemi <[email-masked]>
Date: Thu, 03 Jun 2004 15:38:02 +0300

All,

I think I agree with Eric here. It seems DSN is a very heavy duty tool 
for doing a simple thing, namely respond e2e with an error if things 
don't go as planned, or with a success if things went right. The fact 
that you have to bury this status code inside a DSN does not change the 
fact that it is an error response. Why do I have to implement yet 
another RFC to do this?

Making DSNs optional is also a bit weird. If you really don't care what 
happens to your SEND, then drop the transaction state as soon as you get 
any response from any upstream node. The other end may still send the 
final reports, but they will simply be dropped to the floor.

So, my proposal for how I think the transactions should work in MSRP 
with or without relays is that every request gets an end-to-end 
acknowledgement in the form of an MSRP response. In addition, relays may 
choose to send provisional responses to tell the downstream node that a 
message was received and is being sent onwards. Sort of like:

  A                R1            R2                B
  |                |              |                |
  |-----SEND------>|              |                |
  |                |              |                |
  |<--100 Progress-|              |                |
  |                |----SEND----->|                |
  |                |              |                |
  |                |<--100 Prog.--|                |
  |                |              |----SEND------->|
  |                |              |                |
  |                |              |<---200 OK -----|
  |                |<---200 OK ---|                |
  |<---200 OK -----|              |                |
  |                |              |                |

To me it looks pretty much exactly like it is currently defined in MSRP, 
but without having to introduce the DSNs etc.

The important property however is that you have one way and one way only 
to respond end-to-end (that is, using response codes > 199). If you take 
the relays out of the picture, everyting stays exactly the same, except 
that the sender only gets final responses and no intermediate ones.

A relay that chooses not to take on any state maintenance whatsoever, 
will simply forward data back and forth, and not indicate its existence 
with a 1xx. However, if it chooses to re-chunk or something, it will 
need to respond back with occasional 100s, and in case the upstream 
fails, generate a 4xx.

Thoughts?

Cheers,
Aki

ext Ben Campbell wrote:
> Oops, itchy trigger finger. I meant to say that, with relays, you either 
> need to make an upstream transaction pend on a downstream transaction, 
> which has nasty chaining properties; or you need some way for a relay to 
> tell you that it could not deliver the message.
> 
> Ben Campbell wrote:
> 
>> Eric Burger wrote:
>>
>>> I am back after a hiatus.
>>>
>>> I have not read the latest message-sessions draft.  However, I have read
>>> some discussions on the list about it.
>>>
>>> One substantive issue: The status code is NOT a parsing of the three 
>>> digits
>>> of HTTP/SIP.  The first digit does map directly.  However, the other
>>> segments are 3-digit sequences conveying much more detailed status
>>> information.
>>>
>>>
>>> A bigger issue comes out when you read the discussions on DSN, 
>>> fragments,
>>> SAR, message size, etc.  From a big picture, a high-level description of
>>> MSRP is... "We have invented TCP, and it runs over TCP."
>>>
>>> What triggered this thought?  The idea of tossing DSN's after a session
>>> completes.  This brings us right back to where we started: DSN's DO 
>>> NOT MAKE
>>> SENSE FOR SESSION MODE TRANSACTIONS.  They make sense for 
>>> store-and-forward,
>>> but they do not for interactive sessions.  We have Layer 8 (user) 
>>> protocols
>>> to deal with it, e.g., "did you get my message?".
>>
>>
>>
>> I agree they don't make sense for peer to peer sessions. That is why 
>> we want them to be optional. Further, it may make sense to make the 
>> default be no DSN at all, at least for peer to peer sessions.
>>
>> But when you introduce relays, the fact that you successfully 
>> delivered a message to the relay does not mean the relay can 
>> successfully deliver it downstream. This means you either have to make 
>> the upstre
>>
>>
>>>
>>> If the counter-argument is, "what if they didn't read it", then I would
>>> suggest sending a registered letter.  But seriously, I didn't know that
>>> replacing SMTP was in the charter.
>>>
>>> -- 
>>> - Eric
>>>
>>> P.S. Unfortunately, I will not be attending the f2f, so don't hold back
>>> responses - either privately or on the list.
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/simple
>>
>>
>>
>>
> 
> 
> _______________________________________________
> 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: Ben Campbell <[email-masked]>
Date: Thu, 03 Jun 2004 13:31:07 -0500

> fact that it is an error response. Why do I have to implement yet 

I am open to the suggestion that we don't really need the DSN payload 
format. It may be enough to have a couple of headers to carry status and 
correlation info.

> final reports, but they will simply be dropped to the floor.

The advantage of making dsn optional is the fact that, if the sender 
chooses to request no DSN, then any relay can _also_ drop state.

> but without having to introduce the DSNs etc.

I don't like the idea of having SEND transactions pend for upstream 
responses.

The point of the DSN model is to say that status reporting between 
non-adjacent hops is asynchronous.

> need to respond back with occasional 100s, and in case the upstream 

That approach does not seem to me to be better or worse than the MSRP 
approach discussed in Boston--just different.

> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> ext Ben Campbell wrote:
> 
>> Oops, itchy trigger finger. I meant to say that, with relays, you 
>> either need to make an upstream transaction pend on a downstream 
>> transaction, which has nasty chaining properties; or you need some way 
>> for a relay to tell you that it could not deliver the message.
>>
>> Ben Campbell wrote:
>>
>>> Eric Burger wrote:
>>>
>>> successfully deliver it downstream. This means you either have to 
>>> make the upstre
>>>
>>>
>>>>

---

From: Aki Niemi <[email-masked]>
Date: Fri, 04 Jun 2004 17:33:47 +0300

Inline.

> format. It may be enough to have a couple of headers to carry status and 

At a minimum, a header and correlating ID in a REPORT would seem like an
OK approach. In terms of transaction model, I still don't see what the
big difference in that approach would be to the one I outlined in the
post. More on this below...

> chooses to request no DSN, then any relay can _also_ drop state

I'm still confused by something here. So basically we are saying there
needs to be two types of messages: SEND, and OPPORTNISTIC-SEND, where
with SEND the sender is interested to know what happens to the request
thus requiring a response; with OPPORTUNISTIC-SEND the sender simply
doesn't care and needs no responses whatsoever.

I can't think of a sender who would use OPPORTUNISTIC-SEND in an MSRP
session. At least there doesn't seem to be any benefits to using it -
only drawbacks (i.e., you don't know even if the other end supported the
media type).

So in the worst case scenario, relays are never able to work without
maintaining the transaction state, if all messages are bound to be
SENDs. There is a conflict of interest between the sender and the
relays, and I think we really need a way that a relay can choose to be
stateless, irrespective of the method.

> I don't like the idea of having SEND transactions pend for upstream 

That's already what you have with SEND-200OK-REPORT, no? The sender can
only discard the transaction state once it gets a success report.

> non-adjacent hops is asynchronous.

Meaning that not each chunk (SEND transaction) needs a response, but a
response is generated only after the full message has been received?

So we make it so that a 200 OK is only generated when the all chunks
have arrived. Of course, there could be a 4xx even before that, and
things would still work, right?

> approach discussed in Boston--just different.

I think it is better in that the decision of whether a relay is to take
on state maintenance or not is based not on the sender (DSN or no DSN
requested), but on the relay's local policy and behavior.

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Fri, 04 Jun 2004 13:41:57 -0500

Aki Niemi wrote:

[...]
> only drawbacks (i.e., you don't know even if the other end supported the

I have never said that I think the opportunistic send is a good thing. 
Other's have stated it as a requirement, which the work group has not 
overruled so far.

> stateless, irrespective of the method.

It is possible to build a service where a relay rejects messages that do 
not conform to its reporting policy, as a policy violation. Clients 
would be free to resend without report requests. I personally would not 
build a service this way, but others have said that they intend to.

[...]

> only discard the transaction state once it gets a success report.

Typically, no. This would only be true if you had requested success 
reports. More typically, the sending client discards state as soon as it 
sees the 200OK. If they later get a failure report, they simply tell the 
user they got a failure report. The "report" is an independent 
transaction from the "send".