Subject: [Simple] Questions regarding MSRP drafts

From: Remi Denis-Courmont <[email-masked]>
Date: Wed, 10 Aug 2005 14:39:56 +0300

Hello,

I'm new here. Below are a few non-editorial concerns I have encountered
with draft-ietf-simple-message-sessions-11 and
draft-ietf-simple-msrp-relays-05.

Sessions and connections
-------------------------

  draft-ietf-simple-message-sessions-11 mandates that clients only use
one connection for a given session. Besides, these are supposed to
reject any request belonging to a session that is already attached to
another TCP connection that the one the request came from. That is not
only good for security's sake, but also helps TCP congestion detection
work properly.

  It might be a good idea to explicit that relays do have to obey this
requirement as well, otherwise last-hop MSRP connections may fail. Also
a policy in case of TCP connection failure ought to to be defined:
 - stall all attached sessions (like in the case of client), or,
 - keep trying to establish a new connection for sometime and, if
 successful, retransmit all requests until, not including, the last one
 that was acknolegded somehow, or,
 - something else...

Re-ordering
------------

  Given chunks are sent in order, there are two reasons why chunks might
be seem disordered at the receiving endpoint:
 - chunk loss if an intermediary relay-to-relay connection failed,
 - use of multiple TCP connections for the same hop.

  Both problems are specific to the use of MSRP relays, i.e. ALG.
Because there is no receive window in MSRP, end point should accept
chunks way ahead of the current offset of orderly received data for a
given message.
  In practice, it can probably be assumed that MSRP-using software will
expect ordered data, like TCP-using software expects the IP stack to
perform re-ordering transparently. Without receive window, the receiving
end point could easily be made memory exhausted, as someone could
(purposedly or not) not send a given chunk, of a very long message and
force the MSRP layer into queuing a huge amount of data in its input
buffer. This problem is actually very likely to show up in case a chunk
is lost, but the sender is not notified (e.g., if it doesn't want to).

  To avoid the problem, the receiver is bound to send a defensive 413
error and stall the entire message.

  It is unclear to me whether relays have to use a single TCP connection
for every requests belonging to a given session (while that is
explicitly what clients have to do). I however assume they have to (see
previous note).
  Then why not mandate that relays do NOT re-order chunks. That is,
relays would have to forward all SEND requests in the same order has
they received them (do not actually have to check Byte-Range for that).
Splitting requests into smaller chunk can still be allowed. By the way,
that also helps the sender decide how to prioritize multiple messages in
the same session. If I am not mistaken that is sufficient to ensure that
reordering will never happen and need not be supported by MSRP clients.

Buffer overwriting
-------------------

  draft-ietf-simple-message-sessions-11 recommends that, in case of
chunk retransmit, the end point overwrites already received data with
newly received one. While it is only a SHOULD, there does not seem to be
any reason for this. It is illegal to receive new data that would not
match previously received chunks anyway. Actually, I'd rather consider
this as the sign of a hack attempt. So why should clients do that?

Slow hop after two relays
--------------------------

  If the first relay (I mean, that directly after the sender) detects a
slow/congested link with the subsequent hop, it may stop dequeuing TCP
data from the client. However, that could negatively impact other faster
sessions between the client and other peers.

  If a relay that is not directly after the sender, the only way to
handle a slow downstream connection is to store requests and responses
in some buffer. Otherwise, it would be open to a trivial DoS whereby a
fast malicious client behind a "major" entity (typically an ISP) relay
sends a lot of data to be relayed to a purposedly slow receiver behind
another major entity relay. The TCP connection between the second relay
and the slow receiver would quickly fulfill its TCP window.

  MSRP is meant to allow forwarding of huge files. In the current draft,
the example of a gigabyte-worth message is eventually provided. On the
one hand, buffering such a big amount of data for a single message is
obviously inappropriate. On the other hand, returning an error that the
message is too big to be queued is not satisfying given the
applicability of the MSRP drafts. IMHO, that needs to be addressed
somehow.

  One solution would be to redesign MSRP relays so that they work more
like HTTP CONNECT proxying, or SOCK servers, that is, blindly forwards
data between two TCP connections, and leave it up to the TCP/IP stack to
handle congestion end-to-end.
  Other advantages of this solution include relying on TCP for
retransmission and reordering, making REPORT acknowledgement
potentialy much simpler and less costly, and allowing end-to-end TLS for
security's sake.
  The main limitation is the need for a reverse connection proxy, such
as draft-rosenberg-midcom-turn-08.

  An alternative would consist of allowing relays to drop chunk if they
want to, recommending that partial Failure-Report be always used for big
messages, and allowing the sender to retransmit chunk (or is that
allowed already?).
  However, this is very much like reimplementing sort of TCP on top of
TCP, which is probably highly suboptimal.

  Another alternative is to mandate the use of a limited window (say
64k) that would be the biggest amount of bytes a sender can safely send
without receiving REPORTs acknowledgements. That implies mandating some
kind of positive acknowledgement from the receiver (at the moment, it is
only mandatory at the end of a full message).
  Also, both alternatives could probably be mixed together. Again, that
sounds like reimplementing TCP on top of TCP.

No 500 error code
------------------

  There is no error code like 500 in other protocols to tell the other
side than processing its request failed for a reason that is independant
from the protocol itself (too busy, not enough memory, etc).

-- 
Remi Denis-Courmont <[email-masked]>
Nokia-NRC/Helsinki

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2005 16:33:36 -0400

Remi,

Wish you had been around a year or so ago when most of the decisions 
were made. Comments inline.

	Paul

> draft-ietf-simple-msrp-relays-05.

I'm not sure what you are suggesting here. Each endpoint has a single 
connection to its adjacent relay for any given session. It is only 
connections between relays that can come and go. And they *need* to be 
able to come and go since they have no visibility to or influence over 
session establishment.

>  that was acknolegded somehow, or,

I don't remember what is in there now for this.

> Re-ordering

I believe this is explicitly *not* required. It is generally a goal that 
relays need keep minimal state. Remembering all the sessions and their 
associated connection is a problem. Also, sessions could be up for a 
very long time (potentially days). While the connections at the ends are 
required, I don't think we would want to mandate that connections 
between relays be kept up in that case. So we have given relays 
permission to tear down connections between themselves when not active.

> they received them (do not actually have to check Byte-Range for that).

The cases where reordering can occur are actually pretty obscure I 
think. (Somebody correct me if I am wrong.) The one I can think of is:

- Two connections between a pair of relays. Two messages from same 
connection get sent, one over each connection. The 1st message is very 
long, while the 2nd is very short. The last byte of the 2nd message may 
be received before the last byte of the first message. Then it gets 
forwarded on.

I suspect there are others, but maybe not. Could it be designed out of 
the protocol? I'm not sure. What I do know is that this protocol has 
been beat to death trying to solve everybody's favorite problem. We just 
want it to be done.

> reordering will never happen and need not be supported by MSRP clients.

I agree with you on this one. I wanted it to be an error for any 
overlapping data to differ from the original. (Without requiring that 
this error be detected.) But I was outvoted.

> Slow hop after two relays

This was one of those places where we could not find any solution that 
met all needs. We ultimately decided that we would let the relay deal 
with this be lots of buffering as the lesser of evils. (Put a disk on 
the server.)

	Paul

---

From: Remi Denis-Courmont <[email-masked]>
Date: Thu, 11 Aug 2005 16:30:15 +0300

Hello,

> be received before the last byte of the first message. Then it gets 

That only happens if relays are to maintain multiple connections to the
same peer. Might be wrong, but I doubt ensuring they only have one
connection at a time (of course renewing should it fail) would pose any
problem nor much additionnal load.

On the other hand, supporting re-ordering, without any sane limit on the
re-ordering window size sounds very dangerous and prone to abuse to me.
At least, there ought to be an error code for client not able or not
willing to accept a chunk because of memory constraints.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2005 17:53:46 -0400

Remi,

Lets see what others have to say. I think most people just want this 
done. It has been restarted multiple times over a couple of years, and 
we just can't afford for it not to be done. If we were to reopen it for 
the kinds of changes you are suggesting we would effectively be 
reengineering it from scratch - these kind of changes are fundamental.

	Paul

Remi Denis-Courmont wrote:
> 	Hello,
> 
> Le mer 10/08/2005 Ã  23:33, ext Paul Kyzivat a Ã©crit :
>

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 12 Aug 2005 01:13:16 +0300

I think that it should be done and finished with. If someone has ideas how 
to improve it,
they can suggest another alternative on a new draft and a new work item.

SIP implementations can not afford not finishing with MSRP now. Session IM 
is more
then needed for deployments.

Avshalom
IBM

Paul Kyzivat <[email-masked]> 
Sent by: [email-masked]
12/08/2005 12:53 AM

To
Remi Denis-Courmont <[email-masked]>
cc
SIMPLE <[email-masked]>
Subject
Re: [Simple] Questions regarding MSRP drafts

Remi,

                 Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Aug 2005 16:58:28 -0500

> problem nor much additionnal load.

Multiple simultaneous connections to the same peer are not required.  
One corner case that was discussed is that a relay sends a message to  
a downstream relay, terminates the connection for whatever reason,  
then reconnects to send a new message--but this connection is in fact  
to a different downstream relay for load balancing reasons. The two  
messages now follow different paths through the network, and cannot  
be guaranteed to arrive in order.

> willing to accept a chunk because of memory constraints.

Reordering should be rare enough that I am not convinced we need to  
solve this problem. But I will as usual yield to the work group  
consensus on that matter. What do others think?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Aug 2005 19:57:08 -0400

> consensus on that matter. What do others think?

I think we don't address this now, in the interest of getting done.

Relays can be built with unreasonable amounts of storage to buffer messages.

	Paul

---

From: Benny Prijono <[email-masked]>
Date: Wed, 17 Aug 2005 13:29:55 +0100

> I think we don't address this now, in the interest of getting done.

I think we may *not* even need to address this at all.
Isn't it the draft-ietf-simple-message-sessions-11 pretty clear about 
this, i.e. client must be prepared to receive out-of-order messages?

IMO that means, implementors of MSRP clients/endpoints SHOULD handle 
out-of-order chunks if they think it's important. And implementors of 
MSRP relays *MAY* implement reordering if they think they're very clever. :)

> Relays can be built with unreasonable amounts of storage to buffer 

That's not necessary. See above.

-benny

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2005 18:23:37 -0400

Sounds good to me. Then the recipient only needs to be able to buffer 
the largest message it wishes to receive.

Relays still need to be able to buffer a lot to cover the case where the 
source link is fast but the target link is slow.

	Paul