[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] Questions regarding MSRP drafts
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 <remi.denis-courmont at nokia.com>
Nokia-NRC/Helsinki
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple