Subject: [AVT] Comments on Section 3.2 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09

From: "Glen Zorn" <[email-masked]>
Date: Thu, 16 Dec 2010 17:49:19 +0700

Throughout the section, references to the section in which the various new
messages are defined would be useful, I think.  Also, the text surrounding
the introduction of the new messages could be simplified considerably; for
example, how about "The client first sends a Port Mapping Request message
(Section 4.1) to port PT." instead of "The client first sends a message to
the server via a new RTCP message, called Port Mapping Request to port PT. "
in Step 3A?

Step 2 says 

       A client cannot keep using the same receive port for different
       unicast sessions since there could be packet leakage when
       switching from one unicast session to another unless each
       received unicast stream has its own distinct Synchronization
       Source (SSRC) identifier to allow the client to filter out the
       undesired packets.  Unless this is guaranteed (which is not often
       easy), a client SHOULD use separate receive ports for subsequent
       unicast sessions.  After a sufficient time, a previously used
       receive port could be used again.

What is "a sufficient time"?  How can a client determine whether or not a
sufficient amount of time has passed?

Step 3B says 

       B.  The server generates an opaque encapsulation (i.e., the
           Token) based on certain information including client's IP
           address.

s/including client's/including the clients/

Step 5 says

	If the client uses the same port for both c0 and c1, the RTCP
reports sent for the
	multicast session keep the P3->c1(=c0) binding alive.  If the client
uses different 
	ports for c0 and c1, the client needs to periodically send an
explicit keep-alive message
	[I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive
during the lifetime of 	the unicast session if the unicast session's
lifetime is likely to exceed the NAT's 
	timeout value.

This passage seems to implicitly assume that NAT(s) exist in the path;
perhaps that assumption could be made explicit and the considerations
surrounding them be more clearly labeled.  Also, shouldn't the end of the
second sentence say something like "if the time between unicast feedback
messages  is likely to exceed the NAT's timeout value"?  How is the client
to ascertain the NAT's timeout value?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Dec 2010 03:30:39 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Thursday, December 16, 2010 5:49 AM
> To: [email-masked]
> Subject: [AVT] Comments on Section 3.2 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09
> 

OK, I will look into this in the revision.
 
> sufficient amount of time has passed?

I don't think there is a rule of thumb here. It should be short, however, no guarantees. 
 
> s/including client's/including the clients/

It is the IP address of a single client. I will say "including the client's IP address".
 
> surrounding them be more clearly labeled.  Also, shouldn't the end of the

We always need to assume there exists a NAT. We can make this explicit here. However, it was mentioned earlier in the example.

> to ascertain the NAT's timeout value?

That sounds more correct as there could be multiple messages keeping the unicast session alive. The client cannot necessarily ascertain the timeout value for its nat device but needs to consider the interval provided in RFC4787. Nat devices are supposed to follow the requirements in RFC4787.

-acbegen
 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 16 Dec 2010 20:11:35 +0700

> It is the IP address of a single client. I will say "including the

Yeah, that's what I _meant_ :-(.

> We always need to assume there exists a NAT. We can make this explicit
> here. However, it was mentioned earlier in the example.

Maybe that's what confused me -- Section 3.1 does say "Between the client
and server, there can be one or more NAT devices", but I interpreted that to
mean "maybe there are, maybe there aren't", not "it's assumed that there
are".

> That sounds more correct as there could be multiple messages keeping the
> unicast session alive. The client cannot necessarily ascertain the
> timeout value for its nat device but needs to consider the interval
> provided in RFC4787. 

Maybe that would be a good thing to point out here.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Dec 2010 14:25:54 +0700

Ali C. Begen (abegen) [mailto://[email-masked]] writes:

...

> provided in RFC4787. Nat devices are supposed to follow the requirements
> in RFC4787.

Sorry, I only just now noticed that Section 8 contains a recommendation for
the frequency of keepalives; maybe just put a pointer to it in Section 3.2?