Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt

From: David Yon <[email-masked]>
Date: Wed, 13 Dec 2000 19:25:58 -0500

Thanks everyone for the warm reception and feedback at the MMUSIC WG 
meeting today.  While it is fresh in everyone's mind, I'd like to collect a 
laundry list of discussion items for the next version of the draft.

Jonathan suggested that we fold in all the connection-oriented protocols 
that we currently know about into the draft.  SSL, TLS, RTSP, et al.  While 
I wish I was an encyclopedia of existing network protocols, I'm not. 
:-)  So if folks could chime in with their favorite connection-oriented 
protocols they would like to see listed, that would help me a great deal.

On that topic, apparently there is an ambiguity as to what is meant by 
"RTP/AVP-TCP".  If there are still issues to be hammered out on how RTP/AVP 
is transported over TCP, I would submit that it is not an issue to be 
addressed by my draft.  On the other hand, correct me if I'm wrong, but I 
*thought* I was hearing that perhaps there were two competing ways to do 
it.  If that's the case, it seems like we should either standardize on one 
approach (elsewhere), or my draft should list two different protocol names 
(i.e., RTP/AVP-TCP-1 and RTP/AVP-TCP-2 for lack of a better naming 
covention).  Feedback on this issue is greatly appreciated.

I didn't hear any dissent on having "direction:both" be the default value, 
any objection?

Brian Rosen spoke with me afterward and suggested that the draft might be 
unnecessarily biased towards TCP, whereas with some minor rewording it 
might expand in scope to all connection-oriented protocols without any 
additional complexity.  Brian if you could elaborate on this a bit that 
would be helpful.  I have a few reservations about it but I'd like to hear 
again what you are looking for so that I'm fully understanding what you are 
after.

Several people pointed out that my firewall example was flawed, at least in 
the case of the firewall performing N/PAT.  Well, yes.  But I would just 
like to clarify that the draft, by itself, is not a complete firewall 
solution nor is it intended to be.  It can, in some cases, help the 
situation by (a) allowing media endpoints be more firewall friendly, and 
(b) making it easier to write ALP's as the long-term solution.  But at the 
end of the day it is a non-goal for this draft to provide a complete answer 
to the firewall and N/PAT boondoggle.

Based on the meeting, that's all I can think of for open issues.  If anyone 
else has comments feel free to elaborate.

And thanks again to everyone!

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Dec 2000 04:00:33 -0500

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2000 4:26 PM
> To: [email-masked]
> Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
> 
> 
> that we currently know about into the draft.  SSL, TLS, RTSP, 
> et al. 

SCTP (rfc2960), not RTSP.

> While 

I think if we have TLS (no need for a separate SSL identifier), TCP, and
SCTP, we are covered.

> addressed by my draft.

rfc1890bis,
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt,
defines a default encapsulation format when none is defined. THis format is
simply to append each packet with a two byte length. There is a somewhat
annoying problem here, however.

The tcpmedia draft would depend on this mechanism as a normative reference.
Thus, it could not proceed to proposed until rfc1890bis goes to draft. At
the current pace, that should be sometime in 2005.

So, we have a few options. THe best one is to probably define a separate
"Generic transport of RTP over stream protocols", which is a one page
document that says "append each packet with a two byte length". Then, we can
progress that document alone to proposed along with the tcpmedia draft,
which would reference it.

The other encapsulation, defined by RTSP (rfc2326), is interesting. It
encapsulates the RTP stream within the same TCP connection that carries RTSP
messages. What is interesting about it is that we could conceivably do the
same for SIP; I think this is orthogonal to the SDP issue, but interesting
to consider. Might be a somewhat cleaner way to deal with firewalls and
NATs.

Note that RTSP calls the usage of TCP over the RTSP TCP connection
"RTP/AVP/TCP".

> I didn't hear any dissent on having "direction:both" be the 

I think that this is the most reasonable thing. Anything else would require
a different default in each direction, which is more confusing.

> understanding what you are 

I think the only issue is really the tokens to identify the protocols. The
action of "opening a connection" is common to all connection oriented
transports.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "James Undery" <[email-masked]>
Date: Thu, 14 Dec 2000 23:35:48 -0000

>From: Jonathan Rosenberg <[email-masked]>

>I think if we have TLS (no need for a separate SSL identifier), TCP, and
Another protocol in the pipeline is BXXP which has been submitted to the 
IESG as draft-ietf-beep-framework-08.txt, although if this should be 
included until it is confirmed on the standards track procedure I wouldn't 
like to comment.

James Undery [email-masked]

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 4 Jan 2001 15:39:24 -0500

A colleague's question makes me wonder if IPSEC falls into the
connection-oriented category.  How do you specify that a particuular stream
is to run over an IPSEC tunnel?

> Sent: Wednesday, December 13, 2000 7:26 PM
> To: [email-masked]
> et al.  While

---

From: David Yon <[email-masked]>
Date: Mon, 29 Jan 2001 10:50:22 -0500

Finally getting a chance to spin a new version of the draft...

>I think if we have TLS (no need for a separate SSL identifier), TCP, and

The problem with SCTP is that it allows each endpoint to be comprised of 
multiple IP addresses, which:

         (a) is not possible to express in SDP, and
         (b) the draft in question does nothing to remedy

While I appreciate the notion that we want to cover as many protocols as we 
can in this draft, it's looking to me like expressing SCTP in SDP requires 
its own draft which then references this one.

The alternative is that we just live with the fact that this draft will not 
address the problem of SCTP endpoints have multiple IP addresses.

>Note that RTSP calls the usage of TCP over the RTSP TCP connection

Anyone have an opinion on these options?  Do we want to just have this 
draft reference RTSP?  Or does anyone care about RFC1890bis enough to draft 
the one-pager that Jonathan mentions?  I'm not enough of a RTP expert to 
qualify.

>action of "opening a connection" is common to all connection oriented

Given the possible inclusion of SCTP in the draft, I'm going to scrub most 
of the references to TCP out of it and just talk about "connection setup" 
in the abstract.  It also begs the question of title, I propose renaming 
the draft as follows:

Connection-Oriented Media Transport in SDP
  <draft-ietf-mmusic-sdp-comedia-01.txt>

Any comments?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

---

From: David Yon <[email-masked]>
Date: Mon, 29 Jan 2001 10:53:33 -0500

At 03:39 PM 1/4/01 -0500, Tom-PT Taylor wrote:

>connection-oriented category.  How do you specify that a particuular 
>stream is to run over an IPSEC tunnel?

I don't know enough about IPSEC to understand the issues.  I think the 
first question I would ask is: Can an IPSEC tunnel be described using only 
a single IP Address/Port and connection setup direction attribute?  If not, 
it seems like it would be a follow-on draft that defines all the necessary 
information except for connection setup, which would simply reference this 
draft.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]