Simplifying the mitigation text

Since there is no "one size fits all" mitigation, simplify the recommendations. The point is to draw attention to the problem, and trust developers to do the right thing.

draft-ietf-quic-transport.md

@@ -2703,8 +2703,7 @@ An adversarial endpoint might intentionally fragment the data on
 stream buffers in order to cause disproportionate memory commitment.
 The adversarial endpoint would open a stream,
 and send some STREAM DATA packets containing arbitrary
-fragments of the stream content. This attack can be
-amplifed if used by multiple clients against a single server.
+fragments of the stream content.
 
 The attack is mitigated if flow control windows correspond to
 available memory. However, some receivers will over-commit memory and advertise
@@ -2713,16 +2712,10 @@ The over-commitment strategy may leads to better performance when
 endpoints are well behaved, but renders endpoints vulnerable to
 the stream fragmentation attack.
 
-Endpoints that over commit memory should mitigate this attack.
-A possible mitigation is for servers to keep a count of the number of
-"reassembly holes" in data streams received from the client.
-In normal operation,
-these holes are caused by transmission errors and
-are promptly filled by the
-recovery processes. An abnormal number of holes is caused by either a
-very large rate of transmission errors, or by
-adversarial client behavior. In both
-cases, it is reasonable for the server to close the connection.
+QUIC deployments SHOULD provide mitigations against the stream fragmentation
+attack. Mitigations MAY consist of avoiding over-committing memory, delaying
+reassembly of STREAM DATA frames, implementing heuristics based the
+age and duration of reassembly holes, or some combination.
 
 # IANA Considerations