Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 17:33:43 +0100

Hi,

The second issue is getting back to the unicast RTP session termination.

Having re-read this document it is very clear on when an Unicast RTP
session is created. Section 3.2, bullet 4 makes this clear. However,
there is no discussion on what the criterias are for when the session
can be considered terminated.

This has previously been discussed in my review comments for 08 version
but we didn't conclude on the discussion due to me being unable to
respond then.

To follow up on one thing. Yes, if we had an architectural and usage
requirements document for unicast sessions created in relation to
multicast then that document would make sense to discuss this issue. As
I see it now, that will not be created. This is the usage independent
component so I think it makes sense to discuss it here, even if not
perfectly fit. But I like to point out that creation and some other
treatment things are discussed. So lets include how it is terminated.

The reason i think it is important to discuss is that the end-points
need to know when the other side will consider it terminated and create
a new session in its eyes rather than continue using the current one.
Also, the other signaling mechanisms do have some way of terminating.
SIP Dialog termination kills the media RTP sessions, they can also
become terminated in SDP by re-invites. RTSP has its Teardown method.
SAP relies on SDP t= attribute to tell when the session is valid.

But for this solution it is unclear. That becomes a bit more problematic
as this is a protocol that is intended for highly dynamic cases, like
RAMS. So I would really like to know what the criteria are. Otherwise we
can have clients sending RTCP to a server for a session it considers
closed. It also become a point of resource handling. One should clean up
what one create.

I am fine making this timeout based, like 5 regular report interval (or
TRR-int) without RTP activity. But I think we need to consider what it
means if one peer sends BYE. Can you time out earlier then?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:33:01 -0800

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, January 14, 2011 5:34 PM
> To: IETF AVT WG; [email-masked]
> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination
> 
> Hi,
> 

Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the 3550 rules apply as usual. It is because it is the unicast session that is the important here. This draft cannot say anything at all how the sessions established by using this draft should be terminated.
 
> treatment things are discussed. So lets include how it is terminated.

I disagree. It is up to the unicast session how long it lasts or when it ends. E.g., if it is a retransmission session, it could be used for one rtx and then may never get used, eventually it will time out. Or, the client keeps asking for rtx and it will stay open. It has nothing to do with the token or port mapping.
 
> a new session in its eyes rather than continue using the current one.

Server does not need to know anything other than usual RTP rules. When the session times out, it is done. 

> means if one peer sends BYE. Can you time out earlier then?

If there is a BYE in the unicast, of course, it will end without waiting for the 5xinterval timeout duration. I don't see why we need to say something about this on top of what is already in the text.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 11:54:19 +0100

> Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the 3550 rules apply as usual. It is because it is the unicast session that is t…

The issue, I have is that you say RFC 3550 rules. I don't see how RFC
3550 applies to RTP session termination. Because that happening through
external mechanism. RFC 3550 discusses when to consider an SSRC timed
out. But that is not the same as terminating the session.

It might be that you need to tell any using specification to declare how
a unicast session is terminated. But currently this is a gapping whole
in the specification.

Based on the below comments it appears that you have decided that RTP
session termination is when all external SSRCs has timed out. But, I
wonder if the servers really are fine with that. If I as a client
continue to send RTCP RR to a server in a RAMS scenario for the unicast
session, then the server is not allowed to terminate the session? I
think they will consider the session terminated when the burst is
completed.

For NACK I think one can take two approaches. One more aggressive, but
both appear to work.

A. Lazy, server and client consider the session terminated when the far
side SSRC times out completely. This will not happen as long as both
end-points sees each other RTCP RR even if no data traffic is present.

B. More aggressive: The RTP session is timed out when no RTP data
traffic has been sent in the RTP session for 2 or 5 regular RTCP
reporting intervals.

Once more my summary of this topic is: This is not defined nor obvious
as this is an issue that has not existed prior to using RTP/RTCP for
creating new RTP sessions.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 05:23:51 -0800

> Sent: Monday, January 17, 2011 5:54 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [email-masked]
> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination
> 
> > Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the
> 3550 rules apply as usual. It is because it is the unicast session that is the important here. This draft cannot say anything at all
> how the sessions established by using this draft should be terminated.
> 

As a good citizen, the client can send a BYE to end the unicast session. It is not just when SSRC times out.
 
> a unicast session is terminated. But currently this is a gapping whole

Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed. So, maybe we should simply say the spec using the Token approach needs to discuss the session termination and ending sessions. 
 
> session, then the server is not allowed to terminate the session? I

In RAMS, the client will continue sending RRs if and only if the client does retransmissions in that unicast session. If that is the case, of course, the server is fine since the session is still active.

If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session will end after the timeout.

> think they will consider the session terminated when the burst is

Not necessarily. RAMS server is not just a burst server,  it is a retransmission server, too.
 
> creating new RTP sessions.

The difference is in creating the RTP session not ending it. Just because a session is dynamically created via RTCP does not mean that it must have a different termination method from the regularly established RTP sessions (3550). Once a session is up, it is up - no difference from any other regular RTP session. Following the KISS principle here makes sense IMO.

Cheers,
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 16:12:40 +0100

> As a good citizen, the client can send a BYE to end the unicast session. It is not just when SSRC times out.
Sure, but it is the criteria that is the question.

> Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed. So, maybe we should simply say the spec using the Token approach needs t…

No, if that requirement is put on application of this, then I am mostly
happy.

> If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session will end after the timeout.

But, basically you are saying that unless the client keeps the session
alive, the server will terminate it. Which gives non symmetric behavior
between the client and the retransmission server.

> The difference is in creating the RTP session not ending it. Just because a session is dynamically created via RTCP does not mean that it must have a different termination method from the regularly…

Well, you have above described a system for retransmissions where there
is a difference between the client and the server. And where there is
cases for when the session is considered terminated. That is not the
same as saying that it isn't terminated. I haven't argued that they must
be an explicit message. Only that the rules are made clear.

I am not certain that the restransmission case is well described here.
And this document is the generalized form of when the unicasat session
is created. I think describing this general case of termiantion has its
point. And with the general case I mean:

If the client stops sending RTCP regularly and the client SSRC times out
from the unicast RTP session, the server is allowed to terminate/close
the session. New message for creating it is needed. If the client sends
BYE in the unicast session, the session can also be considered
terminated (Needs Token verification or there is a DOS angle).

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 05:10:38 -0800

> > Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed.
> So, maybe we should simply say the spec using the Token approach needs to discuss the session termination and ending
> sessions.
> 

Just to be clear: are you satisfied if we say " the spec using the Token approach needs to discuss the session termination and ending
Sessions"? If so, do you think we need a 2119 language here?

> > In RAMS, the client will continue sending RRs if and only if the client does retransmissions in that unicast session. If that is
> the case, of course, the server is fine since the session is still active.
> >

In practice, in an IPTV system, this is how it works to the best of my knowledge: The client once it completes a retransmission does not BYE the unicast ret session right after the ret packets were received. It will send the periodic RR/XR reports, if a new NACK is sent, the server is ready to go. When the client switches to another channel, it will BYE that unicast session so the session will end for both sides. Yet, some clients may stop sending reports, so the SSRC will time out on the server side.
 
...
> > The difference is in creating the RTP session not ending it. Just because a session is dynamically created via RTCP does not
> mean that it must have a different termination method from the regularly established RTP sessions (3550). Once a session is
> up, it is up - no difference from any other regular RTP session. Following the KISS principle here makes sense IMO.
> 

Agreed.

> terminated (Needs Token verification or there is a DOS angle).

Also agreed. More on this in an upcoming mail.
 
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 15:21:26 +0100

> Sessions"? If so, do you think we need a 2119 language here?

I have a preference for it, so that it is clear that it can't be skipped.

> In practice, in an IPTV system, this is how it works to the best of my knowledge: The client once it completes a retransmission does not BYE the unicast ret session right after the ret packets were…

Yes, I agree that is the reasonable usage in that scenario. But, I don't
know if everyone will see it in the same light when implementing. Thus
resulting in interoperability issues.

That is why I do wonder if we shouldn't describe this reasonble base
case, and say that applications may modify or specify additional methods
of termination.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 19 Jan 2011 07:22:40 -0800

OK, let's not describe a specific method, and the following text:

A specification using the Token-based authentication described in this document is REQUIRED to discuss the methods and rules for terminating/ending the unicast session.

I propose to add the text above to the 5th parag. of section 3 as follows:

   Upon successful validation and once the unicast session is
   established, all the RTP and RTCP rules specified in [RFC3550] and
   other relevant specifications also apply in this session until it is
   terminated.  >>>

-acbegen

> Sent: Wednesday, January 19, 2011 9:21 AM
> >>> If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session
> will
> >> end after the timeout.
> >>
> > In practice, in an IPTV system, this is how it works to the best of my knowledge: The client once it completes a
> retransmission does not BYE the unicast ret session right after the ret packets were received. It will send the periodic RR/XR
> reports, if a new NACK is sent, the server is ready to go. When the client switches to another channel, it will BYE that unicast
> session so the session will end for both sides. Yet, some clients may stop sending reports, so the SSRC will time out on the
> server side.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 16:53:44 +0100

>    other relevant specifications also apply in this session until it is

Well based on this, I wouldn't come to the conclusion that one can stop
sending RTCP as server at all unless there has been some explicit
signalling for termination. this is Probably fine for the general
introduction. And it do leave the question of termination wide open.

So, I don't see other than that you have to discuss the termination in
the draft.

"The Unicast RTP session created using the port mapping method can be
explicitly terminated by procedures specified by the using application
or extension. Any unicast RTP session created using this method may be
terminated by a timeout procedure. If either client or Retransmission
Server has not seen any RTCP from any SSRC used by a peer for 5 regular
transmission intervals, the client or server SHOULD consider the RTP
session as terminated, and in that case not send any RTP or RTCP traffic
in the future. The client will have to establish a new unicast session
if required.

If no procedure for explicit termination exist, the client MAY stop
sending RTCP to the Retransmission Server to accomplish session
termination. The Server SHALL NOT stop sending RTCP until the unicast
RTP session is terminated. If Token Verification is signaled to be
allowed also on in the unicast RTP session, i.e. the RTCP messages sent
from c2 to P4, the client SHOULD prefer to terminate by sending RTCP BYE
on all SSRCs it has used in this unicast RTP session."

I think this works fine, and is way better than having no specification
at all.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 19 Jan 2011 08:29:40 -0800

OK, this looks good. It maybe needs some 2119 adjustment, though: e.g., if something we say here is already specified in 3550 with a 2119 keyword, I think we better repeat them without a 2119 keyword but do point to 3550.

-acbegen

> Sent: Wednesday, January 19, 2011 10:54 AM
> > A specification using the Token-based authentication described in this document is REQUIRED to discuss the methods and
> rules for terminating/ending the unicast session.
> >