Subject: RE: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)

From: [email-masked]
Date: Wed, 15 Oct 2003 16:48:14 +0300

Hi,

Inline.

 > -----Original Message-----
 > From: ext Robert Sparks [mailto:[email-masked]]
 > Sent: 14 October, 2003 02:31
 > To: [email-masked]
 > Subject: [Simple] Chair call for group opinion (was MSRP: 
 > Administrative
 > shutdown of relays)
 > 
 > 
 > If you have not been  reading the Administrative shutdown of relays
 > thread, the following provides a summary of the possible paths the
 > thread has explored:
 > 
 > In interests of progress _before_ Minnesota, I would like to 
 > get input
 > from people other than the 3 primary participants in the tread as to
 > what they believe is important for us to work on.
 > 
 > So, I am calling an electronic hum. Respond to list or privately to
 > me if you prefer. The questions called are:
 > 
 > One: Do you believe it is important for the document to discuss
 >     administrative shutdown of relays.

No. And I'm going to have to ask a couple of stupid questions, too.

1) Since duplicate delivery is the reason a relay would need to care about shutting down gracefully in the first place, what are the reasons a SEND would time out; who drops it; and why would an MSRP endpoint retransmit if that happens?

2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) and then shutting down?

I thought this is what we wanted to avoid with MSRP. If a relay also processes the SEND (i.e., receives it in entirety before forwarding it along on another connection), this bases a big burden on the relay when the SEND contains a 5GB movie.

Why can't a relay simply peek at the first few bytes of message, see if it is not a BIND or VISIT, and forward it byte-by-byte over to the associated TCP connection. If there is trouble upstream, simply mirror that trouble downstream.

This way, there are never messages in-transit over relay(s) (with the exception of a VISIT, which is always processed by a relay, but can also be forwarded to another target).

If the above simply isn't feasible, then my answer would probably be yes, but I'd have to think between option 1 and 3. 

Regards,
Aki
 
 > Two: (answer only if you answer Yes to question One). 
 >     How much scope creep are we willing to take on?
 >     The options below are listed in increasing scope creep order.
 >     Please respond with which option you would like to see pursued.
 > 
 > Please respond to this call no later than Wed 10/15.
 > 
 > RjS
 >     
 > 
 > 
 > 
 > -----Forwarded Message-----
 > > From: Ben Campbell <[email-masked]>
 > >
 > > It seems to me we have 4 choices:
 > > 
 > > 1) Live with the potential for duplicate deliveries when a logical 
 > > conversation transitions from one session to another in a 
 > short time 
 > > period. Note that this can happen without relays being 
 > involved at all.
 > This potential can be bounded by shorter than inactivity 
 > timeout delays
 > (specifically watiting for transactions already in progress to
 > complete).
 > 
 > >
 > > 2) Require any hosting device that wishes to end a session 
 > wait either 
 > > until connected devices send a request, so that we can 
 > send a response 
 > > indicating that we are shutting down, or until an 
 > inactivity timeout occurs.
 > >
 > > 3) Allow relays to originate a message saying the session 
 > is going down.
 > > 
 > > 4) Create a cross-session duplicate supression mechanism.
 > > 
 > 
 > 
 > 
 > _______________________________________________
 > 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: Wed, 15 Oct 2003 13:41:48 -0400

> 1) Since duplicate delivery is the reason a relay would need to care about shutting down gracefully in the first place, what are the reasons a SEND would time out; who drops it; and why would an MS…

Lets look at application view first. The application has a message to 
send to the other end. Its responsibility is to ensure it gets there. It 
is using an MSRP connection to deliver the message.

Meanwhile the operator of the relay needs to shut down relays from time 
to time.

We want to ensure that the shutting down of the relay doesn't prevent 
the application from ensuring that the messages it sent get to the other 
end.

If the relay is shut down without advance notice of the application, 
there is certainly a chance that a message sent by the app will not 
arrive. If the application wants to survive the relay shutdown, then it 
will need to somehow detect the situation, establish a new connection, 
and retry the send.

Relays shutting down gracefully, and timeouts on messages are simply 
ways for the application to learn what it needs to achieve its ends. 
Without some help, the application can't do this.

> 2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) and then shutting down?

SIP errs on the side of sending duplicates, and depends on the recipient 
to recognize and discard them. Doing the same in MSRP is the 4th choice 
in the vote.

> I thought this is what we wanted to avoid with MSRP. If a relay also processes the SEND (i.e., receives it in entirety before forwarding it along on another connection), this bases a big burden on…

A relay clearly does "process" a SEND, but I don't think we have made 
any require that it receive the whole thing before forwarding it on. If 
that is what you mean we wanted to avoid, then I think we have.

> Why can't a relay simply peek at the first few bytes of message, see if it is not a BIND or VISIT, and forward it byte-by-byte over to the associated TCP connection. If there is trouble upstream, s…

It can. It can also know that it is in the midst of forwarding a 
message. If it wants to shutdown before transmitting the last byte of 
the message, it can send an error response indicating this is what happened.

> This way, there are never messages in-transit over relay(s) (with the exception of a VISIT, which is always processed by a relay, but can also be forwarded to another target).

I don't see why this means there aren't messages in-transit.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Oct 2003 13:41:48 -0400

Paul

---

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 12:38:43 +0300

Hi Paul,

Thanks for the answers. I also had a closer look at the analysis you 
sent in another email, and I think I understand the problem a little 
better, and must agree it exists.

But first off, I'd like to better understand what the requirements for 
relay shutdown are. If there isn't a strict time window, the obvious 
solution is for a relay to reject all new BINDs and VISITs until it has 
no active sessions ongoing, and then shut down.

If the administrator can't wait that long, then I would treat this more 
as an error scenario rather than something we need to document in the 
spec. A relay is supposed to host the session as long as it's active.

So my answer would still be no but a few other things still bothering me 
inline...

On 15.10.2003 20:41, ext Paul Kyzivat:

>> 1) Since duplicate delivery is the reason a relay would need to
>> care about shutting down gracefully in the first place, what are
>> the reasons a SEND would time out; who drops it; and why would an
>> MSRP endpoint retransmit if that happens?
> 
>  send to the other end. Its responsibility is to ensure it gets
> there. It is using an MSRP connection to deliver the message.
> 
> Meanwhile the operator of the relay needs to shut down relays from
> time to time.
> 
>  the application from ensuring that the messages it sent get to the
> other end.
> 
>  arrive. If the application wants to survive the relay shutdown, then
> it will need to somehow detect the situation, establish a new
> connection, and retry the send.

IMO, this behavior is not specified in the spec. Request timeouts are 
interpreted as 5xx, which means the client will resend a few times and 
then give up.

We need text describing how and when an MSRP session transitions to a 
new connection (or alternatively, someone can point me to the existing 
text ;))

>  Without some help, the application can't do this.

Naturally, some help is also provided by the reliable connection the 
MSRP runs on top of.

> SIP errs on the side of sending duplicates, and depends on the
> recipient to recognize and discard them. Doing the same in MSRP is
> the 4th choice in the vote.

Right. I guess the difference in MSRP is that a TR-ID is only unique 
within a connection. Does it need to be? Could option#4 simply be to 
make TR-ID globally unique?

>> I thought this is what we wanted to avoid with MSRP. If a relay
>> also processes the SEND (i.e., receives it in entirety before
>> forwarding it along on another connection), this bases a big burden
>> on the relay when the SEND contains a 5GB movie.
> 
>  any require that it receive the whole thing before forwarding it on.
> If that is what you mean we wanted to avoid, then I think we have.
> 
>> Why can't a relay simply peek at the first few bytes of message,
>> see if it is not a BIND or VISIT, and forward it byte-by-byte over
>> to the associated TCP connection. If there is trouble upstream,
>> simply mirror that trouble downstream.
> 

Except that an MSRP client probably isn't expecting a response to a 
request it is still in the process of sending?

>> This way, there are never messages in-transit over relay(s) (with
>> the exception of a VISIT, which is always processed by a relay, but
>> can also be forwarded to another target).
> 

You're right. The problem does not go away. Even though there might be 
fewer states the system could be in, the relay could still shut down 
when the request is pending - and the problem would remain.

Basically, the reason I'm raising these questions is that at least for 
the non-relay case, I would like things to be as simple as in IRC. That 
is, to send a message, you write it to a buffer and flush it. Granted, 
the presence of relays will make things a bit more complicated, but 
still we should avoid adding complexity unless it's absolutely necessary.

Regards,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 12:38:43 +0300

Hi Paul,

Regards,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2003 10:58:53 -0400

> no active sessions ongoing, and then shut down.

I agree that we may need to clarify what the requirements are.

But I doubt the approach you suggest is very practical. It isn't at all 
hard to imagine people keeping sessions open for extended periods of 
time - hours or even days.

> spec. A relay is supposed to host the session as long as it's active.

Its hard to reconcile the possibility that users might want to keep 
sessions open for days with the practical necessity for adminstrators to 
manage their equipment. Imposing such a requirement would mean that the 
only viable implementation of a relay would be a fully redundant fault 
tolerant one.

> new connection (or alternatively, someone can point me to the existing 

I agree that we need this.

BTW, I think the need for this extends beyond MSRP. There is a need for 
a specification about how to recover from media errors in SIP. If you 
are talking on the phone and simply stop receiving media, I think you 
would like to have something done to try to remedy the problem. In the 
worst case you hang up and try again, but it would be nice for the UA to 
attempt something less extreme first. An obvious thing to do is to test 
the signaling channel - perhaps send a reinvite. If you know there are 
external resources involved then you might want to check them too - in 
this case the relay. If an external resource is broken, then you might 
want to update the call with a replacement.

> Naturally, some help is also provided by the reliable connection the 

Some, but not enough. Even with a single end-end reliable connection 
(like tcp), at the application level you typically don't know which 
bytes were delivered and which were not.

> make TR-ID globally unique?

Perhaps. But then I don't know how an application would decide when it 
could forget a TR-ID.

> request it is still in the process of sending?

That is certainly something that would need to be clarified. But if one 
failed to check it would simply keep on writing until it finished, or 
until it started getting socket errors. So it might not handle things so 
gracefully.

> still we should avoid adding complexity unless it's absolutely necessary.

Agreed it would be nice if it was simple. But some complexity is ok in 
my book to make it reliable. In the end this will get implemented in 
libraries I presume. Every application doesn't implement its own sip 
stack, so it shouldn't have to implement its own MSRP stack either.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2003 10:58:53 -0400

Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 16 Oct 2003 10:31:39 -0500

> no active sessions ongoing, and then shut down.

That is exactly how it _would_ have worked when we were refreshing BIND 
and VISIT to keep a session alive. But we changed that mechanism to use 
SEND traffic. A session can stay alive indefinitely, with the relay 
never seeing another BIND or VISIT.

> interpreted as 5xx, which means the client will resend a few times and 

It is not specified--but it is likely that some implementations will 
attempt to resume a session. Other implementations might simply tell the 
user that the session was ended, and the last message(s) may or may not 
have been delivered.

> new connection (or alternatively, someone can point me to the existing 

Why? It is not our lot to define user experience, only to define 
protocol behavior. Different implementers may have entirely different 
requirements here. We assume that some implementers will attempt to 
auto-resume sessions.

> Naturally, some help is also provided by the reliable connection the 

Certainly this is true for some cases. But it cannot guarantee to me 
that in the case where I send a message and get no response, that I know 
that the opposite peer did not receive it.

> make TR-ID globally unique?

That is what I had in mind _if_ we chose to pursue option 4. But it is 
more complex than just that--we would have to worry about how long a 
receivor had to remember what TR-IDs it had seen in the past.

> request it is still in the process of sending?

We already have the ability for the peer endpoint to interrupt a message 
with an early response. It does clobber framing for the connection, and 
therefore requires the peer to also close the connection.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 16 Oct 2003 10:31:39 -0500