Subject: RE: [Simple] MSRP Open Issues

From: [email-masked]
Date: Tue, 18 Nov 2003 16:56:08 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: Tuesday, November 18, 2003 12:05 AM
> To: Simple WG
> Subject: [Simple] MSRP Open Issues
> 
> 
> Here is the list of significant issues and to-do's from the IETF58 
> meeting. At least, it is the list that I am aware of. Please send me 
> anything I may have missed. (Numbers are for naming purposes, 
> and do not 
> indicate priority--with the exception of 1, of course. 3 Also 
> seems high 
> priority due to the number of items that depend on it)
> 
> I plan to have a new rev of the base spec out before the end of 
> December. That rev will include the removal of relays, and the other 
> issues that we have closure on. Items that require more 
> discussion will 
> depend on the status of the discussion.
> 
> -------------------------------------------------
> 1. Remove relays from the base spec. (Saving relay text for relay 
> specific work, of course...) Does this mean that we have to 
> rename the 
> protocol?

MSP is ok.

> 
> 2. Remove text suggesting re-sending failed messages on the same 
> connection. Instead, we should close the connection and 
> re-connect. (See 
> item 3...)

I'm still confused about this one. Long messages might cause a time-out at the sender's side. Perhaps we need to define 3 different behaviours:

a) a timeout
b) an error response
c) broken TCP connection

a) is what I have real concern for when long messages are involved. Is the problem gone when relays are removed?

> 
> 3. Close on handling of broken TCP connection. We discussed in the 
> meeting that we should be able to reconnect without having to 
> re-signal. 
> (I remember now that we had discussed this before, and had a 
> good reason 
> at that time _not_ to do this--I will attempt to further remember the 
> details so we can decide what currently makes sense.)

One endpoint might crash and reboot. Ports might change so you need to re-signal.

> 
> 3.5 Determine if we need explicity un-visit (interacts with 3.)

I think its needed. If the visitor just tears down the TCP connection, the host does not know if the visitor deliberately ended the session, or if something has gone wrong at the visitor side.

> 
> 4. Do we need a cross-connection duplicate suggestion 
> mechanism? I think 
> we said yes, if the new connection is part of the same session as the 
> old. (Needs further list discussion as it interacts with 3...)

Now you are calling sessions connections? I still think retransmission is not needed.

> 
> 5. Generalize MIME handling to include mime version and allow 
> arbitrary 
> MIME headers.
> 
> 6. Add text specifying use of sdp send-only attributes to identify 
> sessions intended for one-way delivery of large content.
> 
> 7. Close on keep-alive handling--needs more list discussion. In 
> particular, do keep-alives need to be bi-directional?

Probably not. a keep-alive from one side results in a 200 from the other. Therefore both sides are alive.

> 
> 8. Add more verbiage in security considerations, particularly 
> considering TLS certificate usage, self-signed certificates, and 
> interactions between TLS and digest authentication. (Cullen 
> volunteered 
> to send text on TLS cert usage.) (This also interacts with 3.)
> 
> 9. A number of nits and editorial fixes.

10. We need normative text about how to construct a second SDP offer/answer exchange.

Regards,
Hisham

> 
> 
> 
> 
> _______________________________________________
> 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: Tue, 18 Nov 2003 09:15:10 -0600

> a) is what I have real concern for when long messages are involved. Is the problem gone when relays are removed?

I think the timeout problem goes away with no relays (Although we do 
want to make sure we do not paint ourselves into a corner where relays 
become impossible.)

> One endpoint might crash and reboot. Ports might change so you need to re-signal.

That is certainly a scenario where reconnecting would not work. I think, 
though, that we had come up with a reason why reconnecting was _never_ a 
good idea; I'm still trying to reconstitute the reasoning.

> I think its needed. If the visitor just tears down the TCP connection, the host does not know if the visitor deliberately ended the session, or if something has gone wrong at the visitor side.

I agree, _if_ we decide to change the specification so that a dropped 
connection no longer automatically destroys the session.

> Now you are calling sessions connections? I still think retransmission is not needed.

I was talking about a situation where we lose a connection and reconnect 
as part of the same session, or a new session that is somehow correlated 
with the first session. This goes back to item 3.

> 10. We need normative text about how to construct a second SDP offer/answer exchange.

Yes, thank you. I will add that one.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Nov 2003 09:15:10 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Nov 2003 11:29:13 -0500

Ben Campbell wrote:
>>> connection. Instead, we should close the connection and re-connect. 
>>> (See item 3...)
>>
>> I'm still confused about this one. Long messages might cause a 
>> time-out at the sender's side. Perhaps we need to define 3 different 
>> behaviours:
>>
>> a) a timeout
>> b) an error response
>> c) broken TCP connection
>>
>> a) is what I have real concern for when long messages are involved. Is 
>> the problem gone when relays are removed?

Even with relays, of the sort we were planning, timeouts shouldn't have 
been an issue any more than congestion in the network is. I don't think 
this has much to do with the size of the message - the timer isn't going 
to start until the last byte of the message is sent. As long as the 
connection is point to point or relays pass on data as they get it, 
there will typically only be a modest amount of data left to transit the 
connection when the last byte is sent. So the chance of timeout is the 
same as if the large preceding amount of data hadn't been sent. In fact 
it is probably less likely because a larger window will have been opened.

Nevertheless, congestion could cause timeouts, and we ought to think 
about the proper recovery from them. The only ones I can think of that 
makes sense are to give up or eliminate the timeout.

Note that this will perhaps get worse if we are going to try again to do 
a traffic multiplexing relay protocol.

> want to make sure we do not paint ourselves into a corner where relays 

You can still get congestion, reducing the rate at which you can get 
data thru the connection.

>>> re-signal. (I remember now that we had discussed this before, and had 
>>> a good reason at that time _not_ to do this--I will attempt to 
>>> further remember the details so we can decide what currently makes 
>>> sense.)
>>

I can recall a couple:

- one was a security issue - giving more opportunity for somebody else 
to try to break in. I'm not convinced this is a valid concern.

- if you can reconnect at any time, the host must be listening for new 
connections all the time. If you say there can only be one, then as soon 
as that one is received then listening can stop. This is potentially 
significant.

>> I think its needed. If the visitor just tears down the TCP connection, 
>> the host does not know if the visitor deliberately ended the session, 
>> or if something has gone wrong at the visitor side.
> 

This ties in with the proceedure for gracefully closing a connection. 
The real question is whether you cna tell if the close was graceful 
without the un-visit. Maybe it is possible if there is signaling that 
announces the close, and both sides then drain data from the connection.

>>> 4. Do we need a cross-connection duplicate suggestion mechanism? I 
>>> think we said yes, if the new connection is part of the same session 
>>> as the old. (Needs further list discussion as it interacts with 3...)

duplicate *suggestion* mechanism???
I'm suggesting that duplicates be sent when failing over, but I don't 
require a special mechanism for making the suggestion. :-)

(I suppose you mean duplicate *suppression* mechanism.)

>> Now you are calling sessions connections? I still think retransmission 

I think perhaps we lack the proper vocabulary here.
Since SIP is the *session* initiation protocol, and SDP is the *session* 
description protocol, I believe we must believe that the thing 
established by an offer/answer exchange of m-lines is a session. In this 
case we use a TCP connection to implement the session.

The case in question is where an offer/answer exchange within a call 
establishes an MSRP session. Then later, in the same call, another 
offer/answer exchange establishes a different MSRP session that 
logically replaces the previous one. Is there some term that describes 
the concatenation of those two MSRP sessions?

I don't think there is, but we need one. It is a bit like "conversation 
space" as specified in draft-ietf-sipping-cc-framework-03.

When there is trouble sending a message over an MSRP session and 
recovery is attempted by replacing the MSRP session with another in the 
same conversation space where retransmission of the failed message over 
the new session may be helpful.

I agree that this may not always be necessary or desirable. But I think 
it is a policy issue, and the protocol should support it. For instance, 
if it is an automaton that is doing the sending, it will probably want 
to retransmit. In the case of a human controlling the sending, if the 
retransmission isn't handled automatically, then the user will probably 
do it manually anyway, but then it becomes a bad idea to suppress the 
possible duplicate. If a human had sent a huge file, he might first send 
a query "did you get the file?" before resending it, which may not be 
practical for an automaton to do.

If we really wanted to get fancy, we could build in stuff for querying 
whether a message had been received, or for having the recipient respond 
in such a way the the resend is aborted if it was already received. But 
I'm not advocating that right now.

>> other. Therefore both sides are alive.

If we can assume that pulling bytes from the connection is a sufficient 
evidence of liveness of the recipient when receiving a large message 
then I agree. But for some implementations that may not be good enough. 
Suppose you had an OS that buffers a *lot* of incoming data. The sender 
might send to a dead application for a long time without knowing there 
is a problem.

Explicit keepalives by the recipient while receiving the large message 
would fix this problem. But they would have to be a separate message, 
with no response, so they could be sent during reception of a large message.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Nov 2003 11:29:13 -0500

I can recall a couple:

	Paul