Subject: RTSP: Section 9.2

From: Rob Lanphier <[email-masked]>
Date: Wed, 14 Jan 1998 01:01:28 -0800

Just one more thing ....

There's a section in draft-07 that got a red flag in AD review.  The problem stems from the current wording of the draft encouraging the retransmission of non-acked RTSP messages *even when RTSP is delivered over TCP*.  After getting together and scratching our heads for a bit, Henning, Anup and I couldn't come up with a compelling case for keeping the current wording (Henning and Anup, I hope I'm not being presumptuous here).  I've proposed new wording below that fixes this problem, which I haven't gotten an immediate allergic reaction from the smaller group I sent this around to earlier this evening :)

Given this fix and a couple of places where the references could be tidier, we'll probably be issuing a draft-08 of RTSP in the next day or so.  As with draft-07, please give us your comments ASAP, since the IESG is already reading over RTSP as we speak.

Here's the only really substantive change, with "-" indicating the stuff that's removed, and "+" indicating the stuff that gets added.

"Old" draft (draft-07):
   9.2 Reliability and Acknowledgements

   Requests are acknowledged by the receiver unless they are sent to a
   multicast group. If there is no acknowledgement, the sender may resend
   the same message after a timeout of one round-trip time (RTT). The
   round-trip time is estimated as in TCP (RFC 1123), with an initial
   round-trip value of 500 ms. An implementation MAY cache the last RTT
   measurement as the initial value for future connections. 
-                                                           If a reliable
-  transport protocol is used to carry RTSP, the timeout value MAY be set
-  to an arbitrarily large value.
-
-    This can greatly increase responsiveness for proxies operating in
-    local-area networks with small RTTs. The mechanism is defined such
-    that the client implementation does not have to be aware of whether
-    a reliable or unreliable transport protocol is being used. It is
-    probably a bad idea to have two reliability mechanisms on top of
-    each other, although the RTSP RTT estimate is likely to be larger
-    than the TCP estimate.
-
   The Timestamp header (Section 12.38) is used to avoid the
 ....

New version: 
   9.2 Reliability and Acknowledgements

   Requests are acknowledged by the receiver unless they are sent to a
   multicast group. If there is no acknowledgement, the sender may resend
   the same message after a timeout of one round-trip time (RTT). The
   round-trip time is estimated as in TCP (RFC 1123), with an initial
   round-trip value of 500 ms. An implementation MAY cache the last RTT
   measurement as the initial value for future connections. 

+  If a reliable transport protocol is used to carry RTSP, the sender
+  SHOULD NOT ever retransmit requests, and instead SHOULD rely on the 
+  underlying transport to enforce reliability.
+
+    Application-level retransmissions on top of a reliable transport (such
+    as TCP) will tend to compound what is potentially an already bad
+    situation, without providing any benefit.  For example, one cannot
+    take advantage of RTSP-level retransmissions using typical TCP
+    operating-system stacks (as of this writing), since these
+    implementations seldom let one look ahead to see data beyond that
+    which was lost in transit.
+
+    If the implemenation is truly capable of benefitting from resends (for
+    instance, greater than usual control of the TCP stack is possible),
+    this can greatly increase responsiveness for proxies operating in
+    local-area networks with small RTTs, since the RTSP RTT estimate can
+    be tuned to be smaller than the TCP estimate.  However, in the case
+    where low-level TCP tweaks can be made, one would hope that the TCP
+    RTT could be tuned directly, eliminating the need to send resends at
+    the RTSP level.

   The Timestamp header (Section 12.38) is used to avoid the
 ....

Let me know if this doesn't make sense.  Otherwise, you'll see this change in the next RTSP draft.

Rob

---
Rob Lanphier ([email-masked])    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Jan 1998 07:33:30 -0500

> +  SHOULD NOT ever retransmit requests, and instead SHOULD rely on the

Just some English tuning, to sound less strident:

SHOULD NOT retransmit

> +  underlying transport to enforce reliability.

provide reliability (it's a service, not a chore...)

> +    situation, without providing any benefit.  For example, one cannot

This is a bit opaque since the example says that you can't win, while
the first sentence says it's bad.

My stab:

If both the underlying reliable transport such as TCP and the
application retransmit requests and responses, it is possible that each
packet loss results in two retransmissions. The receiver cannot
typically take advantage of the application-layer retransmission since
the transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver.

> +    where low-level TCP tweaks can be made, one would hope that the TCP

tweaks -> modifications (I consider RFCs formal writing :-))

> +    RTT could be tuned directly, eliminating the need to send resends at

send resends -> retransmit or resend

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Jan 1998 16:06:31 +0100

I'd also add

If the packet loss is caused by congestion, multiple retransmissions at
different layers will cause even more congestion, making the situation worse.
Therefore, application-layer retramsmission MUST NOT be done.

>> +    RTT could be tuned directly, eliminating the need to send resends at

I'd suggest removing this section entirely, and replacing it with a
sentence saying

If RTSP is used over a small-RTT LAN, standard procedures for optimizing
inital
TCP round trip estimates, such as those used in T/TCP [RFC 1644], can be
beneficial.

Don't reinvent wheels if you can avoid it. ESPECIALLY for protocols that
are likely
to be in standard software deployed in a VERY wide range of conditions,
some of
which will be far outside the makers' imagination.
("home LAN" video player being used in a broadcast studio for feeding a
satellite link?
Don't think it won't happen....)

                         Harald T. Alvestrand
                    one of the IESG commenters

NOTE: New Email address: [email-masked]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997