Subject: [MMUSIC] Notes for 10/01/03 RTSP Telecon

From: Aravind Narasimhan <[email-masked]>
Date: Fri, 03 Oct 2003 09:54:32 -0400

Meeting Notes for 10/01 RTSP Concall

Attendees:

  Magnus Westerlund
  Thomas Zeng
  Aravind Narasimhan
  Greg Sherwood
  Colin Perkins
  Sean Sheedy

Detailed Minutes:

Thomas:  Working on strawman draft for End of Stream
Sean:    Filed end of stream 2 bug years ago.
Magnus:  In feature request area.
Magnus:  3.a. Range header bug.  We have text,  Let's close

Magnus:  3.b. PAUSE in ready state.
Magnus:  Text available in bis04. Any controversy? Take it to list

Magnus   3.c. Multiple SSRC. Let's close
Aravind: has been through multiple iterations in meetings and spec.

Magnus:  3.d. RTP timestamp and pause
Aravind: There is text in 3GPP.
Magnus:  I proof read it.  It should be good.  But we need a good
example in the RTSP Spec.

Magnus:  3.e. "a=range" is missing IANA registration
Magnus:  Has been written up.  Can be closed.  Please review text in bis04

Magnus:  3.f. PLAY at end of media
Magnus:  Written up this month.  Needs to be reviewed.

Magnus:  3.g: Implicit REDIRECT
Magnus:  Resolution in Vienna was a new 300 redirect code so that if you
understand the SDP and 300 code you can go immediately to the new server
and use the SDP.  If you dont understand the code then just redirect and
do an describe.
Greg:    Sounds good.

Vienna Discussion Items:

Colin Joined the call.

Magnus:  3.h. Aggregate URL discussion
Magnus:  Session declarations lacking a session level control URL,
SHOULD be used in non-aggregated control.
Aravind: The main issue is what the rules are for generating the
aggregate control URL.
Magnus:  The wording proposed to have client create aggregate control
URI  in the current text is good.
Aravind: I belive Bill May had an issue with this. Not sure if it is
resolved.
Magnus:  Will post to the mailing list the proposed wording.
Magnus:  I think the rules available which Aravind wrote into bis04
are acceptable. But lets resolve this when I post to the mailing
list the new SETUP text.

Magnus:  3.i.  a=range in SDP to indicate live media
Magnus:  Has been adopted in 3GPP.  I added the wording to CVS.
Thomas:  I dont see any problems with it

Magnus:  3.j. How does REDIRECT method work
Magnus:  Sessions will be terminated by successful REDIRECT
Thomas:  I dont object to this.  But I want to point out that this is
the only server -> client request that changes state
Thomas:  The spirit of not requiring TEARDOWN after redirect is that the
server can get rid of the session.  By having the client doing a
teardown the cleint maintains control of the state machine
Magnus:  It doesn't make sense to have the client send TEARDOWN when the
server needs to go away
Greg:    If the server wants to drop the session but do it
intelligently, it can do so by doing a REDIRECT without location header
which basically indicates to the client that the server is going away.
Greg:    Is it ok for the server to close the connecting when it sends a
REDIRECT?
Magnus:  Connection:close can't be put into work until the complete
transaction is performed. In other words the response must be sent
before closing the TCP connection.
Greg:    The situation where a server would send a REDIRECT is where the
server would have to go down in short order.  So it may want to close
the connection.
Thomas:  Why don't we do that instead of having a redirect always imply
a teardown.
Magnus:  After the client answers RTSP 200 Ok, that can have connection
close header.
Thomas:  Does the server still stay around to get 200 ok.
Greg:    The server may send the connection close header and may not do
anything else and my not stay around for the response.
Thomas:  If the server needs to go away then this wont work.
Greg:    In the case where the server has to go away the server should
wait for the 200k but it is just a courtesy to the client.
Magnus:  There are other considerations especially with proxies in the
middle.  If there are multiple sessions over a single TCP conneciton.
Thomas:  Isnt there a way to do a REDIRECT with out a session header
which tells the server that all the session are going away.  That will
take care of this concern.
Greg:    Please clarify the proxy issue. It is just replicating the
connections to the server, no?
Magnus:  1 TCP connection from proxy to server may be handling multiple
sessions.
Magnus:  Any volunteers to write up?  No.  Leave it waiting.

Magnus:  3.k Indicating end of stream
Thomas:  End of stream strawman draft is almost done.
Sean:    We had a proposal 2 years back based on the way we did it.  It
was a hack based on ANNOUCE, but there are bits of information that the
client wants.  Will Send to thomas for him to incoporate in to his write up
Mangus:  Client will want to know sequence number of the last packet on
the stream.
Thomas:  Specific to RTP-Info: The BNF does allow one of  rtptime or seqnum,
or both, so for response to END_OF_STREAM just seqnum is enough to tell
client what is the ending packet.
Magnus:  Take discussion to mailing list.

Magnus:  3.m Request to response time is not limited.
Magnus:  Response time limit for requests.  There is no indication in
spec right now.  Was pointed out by SIP folks.
Sean:    Would like to second that. Nobody is willing to wait for an
arbitrary amount of time for a response in order to retry.  10 seconsds
seems reasonable.
Thomas:  We need a header parameter in the client request indicating how
long the it is going to wait.
Sean:    If the client sends a request a server, how long should it wait?
Sean:    Should just have a resonable value.
Thomas:  Do you see an issue in having the client send a parameter
indicating client time out?
Sean:    Too complicated.
Greg:    Is there already a precedence for this in SIP?
Magnus:  Had an impression that there is something is SIP.
Collin:  It wouldn't surprise me if SIP has it.  But it may not be the
same thing that is useful for RTSP.
Thomas:  It is the client that knows what it wants to expect.  And since
the server can tell the client of timeout, why not have client do it to
server.
Magnus:  10 seconds should be enough for all purposes here.
Greg:    The server must respond in 10 seconds?
Thomas:  or send 100 response saying I'm working on it.
Greg:    What if the client pipelines hundereds of requests all at the
same time?
Collin:  There are trasnmission delays.  Can only deal with this with
Timestamps.
Magnus:  The requester waits up to 10 second. The responder must answer
within 5 seconds. That way some numbers on transport delay is present.
Thomas:  10 seconds without regard to TCP delays.
Collin:  Does the spec have a section with discussion when it is
appropriate to pipeline commands.
Thomas:  There is no congestions control dicussion on pipeline.
Magnus:  You can pipline n setups, multiple non-aggregated plays or
pause, OPTIONS and DESCRIBE.
Thomas:  Need to handle congestion control too. . .
Collin:  One is cogestgion, the other is that it is going to take a long
time
Sean:    If the server knows it needs to do some serious processing,
then it will send a 100 response.  If no 100 reponse it sent, then there
is a congestion problem somewhere
Sean:    Will attempt to write this up

Magnus:  3.n.  Version number
Mangus:  Aravind is taking a look at the spec for change
Aravind: I am cataloging the spec for changes so that we can have a good
understanding of the scope of the changes.  IT was clear at the Vienna
meeting that we did not have a good handle on this.  Should have a
preliminary list by sometime next week.

Magnus:  4.a TEARDOWN using * and the Ready-nm state.
Magnus:  No need to keep this complication in the state machine.  If you
have no media in your session, your session is gone.
Greg:    Why was this added:
Magnus:  Added a year ago.  It was mainly to preserve some resources on
the server side.  But this seems less useful now.
Aravind: Agreed.
Thomas:  Leaving it in will require more error handling.  What happens
when you do PLAY on a Ready-nm state?
Mangus:  Let's remove this state
Aravind: It complicates the state machine for the normal case.
Magnus:  I will mail the question to the mailing list before removing it

Magnus:  4.b. How to handle sync in re-SETUP
Magnus:  Will use Range and RTP-Info for syncing after RESETUP.  Will
post to list.

Magnus:  4.c. Re-SETUP of transport parameters
Magnus:  There was discussion on the mailing list. Geetha agreed to
write it up.

Magnus:  4.d. Removal of SETUP in play state
Magnus:  SETUP in play state will be removed from the core spec and will
post a mailing list.  It is better to leave this as an extension.
Thomas:  Yes it works better as an extension with the stream switching
stuff.
Aravind: Let's remove it, but let's make sure that we don't make  it
hard to add as an extension.

Magnus:  Next Meeting will be Tuesday, October 14th. That will give use
a week and half to finish up changes to the spec for the November meeting.
Magnus:  October 27th is the deadline for submission to November IETF
meeting.

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

---

From: Tom Marshall <[email-masked]>
Date: Fri, 3 Oct 2003 09:55:29 -0700

I still don't recall anyone explaining why this is an issue. 
Implementations are free to "give up" at any point and, of course, the
end-user ultimately should decide the acceptable delay.  I think the most
sensible way to handle this is to recommend that clients have a default
timeout of X seconds (I would say X no smaller than 60 but that's me) and
the timeout should (must?) be configurable by the user.

The reason I'm so opposed to this idea is that RTSP runs on top of TCP.  TCP
can, and does, mitigate packet loss with retransmissions.  You cannot assume
that just because the client sent a request at time T, the server received
it at (T+RTT/2), and likewise for the server's response.  I've personally
run into high loss networks where responses were delayed for much longer
than 10 seconds due to retransmissions but still wanted the content enough
to wait.  I've also run into physical layer problems (disconnected network
cable, timed out VPN) where correcting the problem allowed the TCP
connection to continue smoothly.  I don't think we should gratuitously break
the RTSP layer sooner than the TCP layer gives up or try to second guess the
TCP layer, especially since RTSP above TCP in the stack.

-- 
One good reason why computers can do more work than people is that they
never have to stop and answer the phone.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Oct 2003 09:28:28 +0200

Hi Tom,

I understand your concerns regarding TCP, and I think your reasoning is 
valid for this part of the problem. The other part is how long a server 
should maximum wait before using a 1xx response code to indicate is the 
other part. This problem arise for example when doing setup and the time 
to get the load the media can be of more than a few seconds, for example 
due to a tape robot.

In these scenarios it is good to have a time limit that tells you how 
long you are at maximum are allowed to delay responding without giving 
any indication that the request is received. Of course in the tape robot 
example if the server knows that this is a tape robot it could usually 
send a 1xx response directly after requesting the media to be loaded.

The client side is still a problem. I guess that one needs to write some 
recommendations on how the client should behave. Having a server side 
limit allow the client to form opinion on lowest possible delay before 
time-out.

Another interesting problem is with proxies. In this case the 
transmission of the request to the proxy goes fast and fine. Then when 
the proxy tries to contact the server the TCP connection takes an long 
time. How long should the client in this case wait?

Another question: For HTTP and SIP after sending a 1xx response, with 
what time period must the server repeat this message during the wait for 
the real response?

In conclusion: There are some considerations to make in this area.

- I think a server side time-out to send a 1xx response is good.

- I think that we must resolve also how the client is recommended to 
behave. This will always be a implementation thing, but guidelines I 
think is good.

Please continue the discussion.

Cheers

Magnus

Tom Marshall wrote:

>>arbitrary amount of time for a response in order to retry.  10
> 
> seconsds
> 
>>seems reasonable.
>>Thomas:  We need a header parameter in the client request indicating
> 
> how
> 
>>Sean:    If the client sends a request a server, how long should it
> 
> wait?
> 
>>Thomas:  It is the client that knows what it wants to expect.  And
> 
> since
> 
>>the server can tell the client of timeout, why not have client do it
> 
> to
> 
>>server.
>>Magnus:  The requester waits up to 10 second. The responder must
> 
> answer
> 
>>Collin:  One is cogestgion, the other is that it is going to take a
> 
> long
> 
>>time
>>then it will send a 100 response.  If no 100 reponse it sent, then
> 
> there
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Sean Sheedy <[email-masked]>
Date: 06 Oct 2003 13:18:15 -0700

I basically agree with Magnus.

Relying on TCP alone is not sufficient.  Although it will provide
reliability to the control connection itself, it's incapable of handling
other congestion or failure events outside of the IP domain.  For
example:
      * Delays in the server's authentication and billing back end.
      * Server failures which still allow incoming requests from the IP
        stack, but which prevent the server from processing the requests
        in any useful way.

Clients need some guidance about the expected response time of the
server to be able to detect these types of failures and deal with them
appropriately.  At the least, it's more user-friendly to be able to say
"The server is not responding" than to simply wait for the user to give
up in frustration.

In practice, every client software author I've worked with has wanted to
know the maximum response time of the server.  I think discussing the
issue in the specification and coming up with some guidelines is better
for interoperability than leaving it entirely up to each implementor.

Sean

-- 
Sean Sheedy                                         [email-masked]
(503) 531-6427

---

From: Tom Marshall <[email-masked]>
Date: Mon, 6 Oct 2003 14:16:16 -0700

>         stack, but which prevent the server from processing the requests

While I agree in principle that a method of handling delays is desirable, I
strongly suggest using _only_ positive feedback (1xx responses).  I want to
ensure that it's crystal clear that negative feedback (no response) is _not_
an indication of failure.  Just about every network application I know about
allows the TCP layer to do its job without imposing arbitrary time limits on
responses.  Try unplugging your network cable and running various programs
that use TCP sockets to see how long they take to fail.  The applications
that do impose arbitrary time limits (our player is one) have configurable
limits for the timeout period.  I'm not thrilled with that solution but at
least the user can adjust the timeout for situations where packet loss or
delay are larger than the implementor expected.

Regarding your second bullet, it does not really matter if the server can
allow incoming requests or not.  The TCP stack will happily accept several
normal sized RTSP requests and queue them even if the network cable is
unplugged.  In the BSD socket API, acceptance for delivery does not imply
anything about whether the data was actually delivered.  One could argue
that a non-BSD implementation could pass up the ACK so that the application
knew the data had been received by the other side, but that only guarantees
that the destination TCP stack has received the data.  It still doesn't say
whether the server application has received it.  If the server is indeed in
a state where it can accept requests but cannot process them for longer than
the TCP is willing to wait (such that the TCP connection is broken) and it
further cannot send 1xx responses to tell the client it's busy, I submit
that the server needs to be redesigned.

> for interoperability than leaving it entirely up to each implementor.

Again, I suggest playing with different network applications to see what
implementors of other protocols have done.

This issue is as old as TCP itself.  I know it's tempting to try second
guessing the network and pop up a dialog that says the server is not
responding, please contact the provider, it's not our fault.  But it's
simply not possible to do this on top of TCP.  The only feedback that you
can give is positive.  If the user gets tired of waiting, let the user press
the "stop" button.  It's not that hard.  Really.

There is also a difference between initial delay when establishing a TCP
connection and the delay in RTSP request/response time.  The usual delay
that causes problems establishing the TCP connection is the DNS lookup. 
When designing guidelines for clients, I think it's critical that we make
this point.  RTSP delay guidelines are in no way a guideline for the
underlying TCP connection and they must _only_ be used after the TCP
connection has been successfully established.

-- 
To err is human; to really screw things up requires the root password.