Subject: RE: [Sip-implementors] problemindraft-ietf-mmusic-sdp-comedia-00?

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 12 Jun 2001 07:19:15 -0700

Paul,

I think we need to look at WHY we are supplying source address information
and what impact it will have. 

- If we are doing it to ensure the source address is consistent with the
transport layer connections then I think is wrong. If enforced it rules out
NAT/NAPT traversal for starters and goes against the existing SDP paradigms.

- Similarly, if this proposal is to allow an application to share a single
local port between multiple media session by dictating the source address
then there are a number of points that I can make with regards to that:
1)	Firstly, plain old udp-based RTP has this restriction so and it is
not the place of comedia to change this in my opinion. Under normal SDP each
media session specifies a UDP or TCP port for receiving media or connections
and you cannot assume anything about the source media address. 
2)	I think it is more common than you think for an IP implementation
not to be able to predict the local address of outbound TCP connections. For
instance: From the Windows getsockname() help file: "A Windows Sockets
application must not assume that the address will be specified unless the
socket is connected. The address that will be used for the socket is unknown
unless the socket is connected when used in a multihomed host." 
3)	This also introduces timing issues that complicate matters (eg, the
remote side must have received and processed your "local" session
description before you can begin to make a connection to the remote side -
it's a race condition). Yuck!
4)	Mechanism fails (badly) when connections traverse a NAT/NAPT - you
will receive a TCP connection at port which you cannot associate with a
unique session description.
5)	Any mechanism for port sharing would most probably end up being be
quite heuristical or complicated and would not be compatible with NAT/NAPT
traversal. I don't think that it belongs or should be encouraged in this
draft. 
6)	If your need for >63K SDP connections on a single host then why
don't you just assign the server multiple IP addresses on the same
interface. Your arguments for complexity are not really valid on a server
handling >63K connections; besides, I think it would be much more
complicated to try to share ports rather than allocate each connection to a
separate port, frankly.

- This addition does not help or address the separation of the send and
receive processes onto different connections. I'm not sure if this was even
a concern of yours Paul? This can be solved using two separate, correlated,
unidirectional media sessions (ie, two a=sendonly/recvonly sessions
correlated using Gonzalo's "fid" draft or application layer correlation). We
could also add another "enforce unidirectionality" parameter to the comedia
draft but in my mind this is an unrelated and perhaps even unnecessary
addition.

So, I would say that IF this is added it should explicitly say that it must
not to be used by an endpoint or application! The information should only be
provided to open holes in application-layer aware firewalls (ALG's). 

This however defeats the reasons that Paul wants the addition in the first
place.

Robert.

-----Original Message-----
From:	Paul Kyzivat [mailto:[email-masked]]
Sent:	Monday, June 11, 2001 10:46 PM
To:	David Yon
Cc:	Fairlie-Cuninghame, Robert; MMUSIC
Subject:	Re: [Sip-implementors]
problemindraft-ietf-mmusic-sdp-comedia-00?

David,

Your meaning of optional was clear in your revised direction-spec.
But you mean something different in the optionality of the port.

But Robert F-C is concerned about the ability to predict what address
will send the connection, and you are obviously concerned about the
ability to predict the port. These concerns are relevant in the case of
Java today.

The listening end needs both of these to match a particular incoming
connection to a specific media description. Otherwise the listener must
dedicate a listening socket to the invitation. The big problem here is
that once something is optional it is tempting for people not to do it.
For instance, a device that only implements direction:active may just
not go to the trouble. But then every device that implements
direction:passive or direction:both must be prepared to deal with this
lack. That both complicates the code and increases resource usage during
invitation processing.

I'm not sure there is any way out of this. But at the least the document
should say that both the port and the address SHOULD be supplied.

	Paul

David Yon wrote:
> 
> At 04:02 PM 6/11/2001, Paul Kyzivat wrote:
> 
> >My problem is that *optionally* specifying the address and port that
> >will be used to connect isn't helpful. If I must accept calls from a UA
> >that doesn't do so, then I must ensure I have another way to distinguish
> >that connection from other connections. The only way I can see to do
> >that is to dedicate a listening socket for the duration of the
> >invitation. I find that to be *very* objectionable.
> 
> Maybe I should elaborate on what I meant by "optional" for the
> address.  It's optional only if the endpoint knows that it will be
> connecting from the same address as listed in the "c=" line.  If the
> address from which it will be connecting is *different* than what is found
> in the "c=" line, then the endpoint MUST specify that address in the
> "direction" attribute.
> 
> Does that help?
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> 402 Amherst St.
> Nashua, NH 03063
> Voice   +1-603-577-8708 x206
> Fax     +1-603-578-9564
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2001 14:00:23 -0400

I want to build a SIP UA something like a gateway - namely it serves as
the endpoint for many different addresses, and may have many calls in
progress concurrently. Each call may have one, or even several, media
sessions. And of course I am interested in media sessions using
connection oriented protocols. For now lets assume they are TCP.

I wish each media session to have one TCP connection of its own (not
shared with any other media session) used to transmit in both
directions. (Lets also ignore for now the case that results in two TCP
connections.) Such a connection will require one socket in the UA.

To achieve this, if the UA has specified direction:passive or
direction:both, it must specify a port on which it will listen for the
incoming connection request and accept it. Now normally when using TCP,
a server will have a single listening socket, and accept whatever
connect requests come along. The comedia proposal doesn't fit this very
well. Suppose I have a single listening socket, and specify it in
multiple concurrent invitations. When a connect request arrives, I can
accept it, but I don't know which of the invitations it belongs to.

The only useful features of an individual accepted socket that I can use
to decide which is which are the address and port of the remote end.
These are sufficient if they were conveyed to me via the other end's
SDP. That is the use I have for the address.

If the connecting address and port aren't both available to me via the
SDP, or if they cannot be trusted, then I only have one other available
means to correctly associate an incoming connection with a media
session: I must ensure that concurrent invitations use distinct
listening ports. A port dedicated in this way is tied up until the
invitation completes - which could be a long time. This could
potentially double the resources (sockets, threads) required to service
a given load.

This is potentially a problem for any UA that could have multiple
invitations pending at the same time. Somehow I find it hard to believe
that everyone would be ok with having to allocate a listening port for
each invitation, accept one connection, and then dispose of the the
listening port at the completion of the invitation.

This is not like UDP. In UDP I have to assign the port I receive on at
the time of the invitation and keep it until the call is completed. 

Is that clear enough?

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Paul,
> 
> I think we need to look at WHY we are supplying source address
> information and what impact it will have.
> 
> - If we are doing it to ensure the source address is consistent with
> the transport layer connections then I think is wrong. If enforced it
> rules out NAT/NAPT traversal for starters and goes against the
> existing SDP paradigms.
> 
> - Similarly, if this proposal is to allow an application to share a
> single local port between multiple media session by dictating the
> source address then there are a number of points that I can make with
> regards to that:
> 
>             1. Firstly, plain old udp-based RTP has this restriction
>                so and it is not the place of comedia to change this in
>                my opinion. Under normal SDP each media session
>                specifies a UDP or TCP port for receiving media or
>                connections and you cannot assume anything about the
>                source media address.
>             2. I think it is more common than you think for an IP
>                implementation not to be able to predict the local
>                address of outbound TCP connections. For instance: From
>                the Windows getsockname() help file: "A Windows Sockets
>                application must not assume that the address will be
>                specified unless the socket is connected. The address
>                that will be used for the socket is unknown unless the
>                socket is connected when used in a multihomed host."
>             3. This also introduces timing issues that complicate
>                matters (eg, the remote side must have received and
>                processed your "local" session description before you
>                can begin to make a connection to the remote side -
>             4. Mechanism fails (badly) when connections traverse a
>                NAT/NAPT - you will receive a TCP connection at port
>                which you cannot associate with a unique session
>                description.
>             5. Any mechanism for port sharing would most probably end
>                up being be quite heuristical or complicated and would
>                not be compatible with NAT/NAPT traversal. I don't
>                think that it belongs or should be encouraged in this
>                draft.
>             6. If your need for >63K SDP connections on a single host
>                then why don't you just assign the server multiple IP
>                addresses on the same interface. Your arguments for
>                complexity are not really valid on a server handling
>                >63K connections; besides, I think it would be much
>                more complicated to try to share ports rather than
>                allocate each connection to a separate port, frankly.
> 
> - This addition does not help or address the separation of the send
> and receive processes onto different connections. I'm not sure if this
> was even a concern of yours Paul? This can be solved using two
> separate, correlated, unidirectional media sessions (ie, two
> a=sendonly/recvonly sessions correlated using Gonzalo's "fid" draft or
> application layer correlation). We could also add another "enforce
> unidirectionality" parameter to the comedia draft but in my mind this
> is an unrelated and perhaps even unnecessary addition.
> 
> So, I would say that IF this is added it should explicitly say that it
> must not to be used by an endpoint or application! The information
> should only be provided to open holes in application-layer aware
> firewalls (ALG's).
> 
> This however defeats the reasons that Paul wants the addition in the
> first place.
> 
> Robert.
>

---

From: David Yon <[email-masked]>
Date: Tue, 12 Jun 2001 17:18:18 -0400

Comments inline:

>SDP. That is the use I have for the address.

comedia at least attempts to address scenarios where each end is able to 
fully specify the information in SDP.  There are at least some deployments 
where that assumption can be made and therefore it is worthwhile including 
the capability in comedia.  Obviously that's not always the case.

>potentially double the resources (sockets, threads) required to service

This is also true of RTCP/UDP media, TCP does not really change this.  If 
you open a dedicated RTCP port pair in response to an invitation, but that 
invitation never turns into a session, you have the same timeout vs 
resource consumption issue.

>the time of the invitation and keep it until the call is completed.

So in other words, for the case where you need to dynamically assign a port 
for a particular invitation:

1) For RTCP you keep two UDP ports open for the entire length of the session.

2) For TCP you have a single listener that morphs into a single connected 
socket during the course of the session.

Seems to me like the server load is comparable, why is this a problem?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2001 18:34:10 -0400

David,

First, I will agree that this is probably not a huge issue.
If I am not misunderstanding anything, and it is indeed necessary to
dedicate listeners during invites, then so be it. But this is an
unusual usage pattern, so I suspected that I was missing something
or else something was wrong.

I also agree with you that in some ways this is comparable to the
non-connection-oriented cases like UDP. But I'm not interested in
comparing it to UDP - it is a different situation, and ought to
be the best it can be.

I am still unclear at this point when, if ever, the passive party
can expect to know which address to expect a connection from. I see
four possibilities:

1) no changes to the published comedia draft. c= represents an address
of a passive party that an active party can connect to. It implies
*nothing* about the address from which an active party will connect.

2) no changes to published syntax in comedia draft. c= represents 
an address of a passive party that an active party can connect to. 
It also is the address a connect will come from.

3) comedia draft changed to have optional address (in addition to
port) on a:direction line. If address is present, it represents the
address from which the active party will connect. If absent, connect 
may come from any address.

4) same as (3) except if address is absent from a:direction line,
connect will come from the address in the c= line.

I believe the status quo is (1) or (2), and it is a problem that
I can't tell which. (4) is the change you earlier suggested in 
response to me. Based on the conversation here, it seems likely 
that (2) and (4) may be impossible for some implementations to
support. It looks to me like the only viable choices are (1) and
(3). If the choice is (1), then it would be good to beef up the
text to ensure nobody thinks it is (2).

	Paul

---

From: David Yon <[email-masked]>
Date: Tue, 12 Jun 2001 18:56:13 -0400

>comparing it to UDP - it is a different situation, and ought to

I agree that resorting to ephemeral TCP listener ports is ugly.  But you're 
right---if the passive UA knows it may be deployed in an environment where 
it cannot be guaranteed that the active UA specifies the source 
address/port (or cannot trust it due to N/PAT) then it doesn't have much of 
a choice.

>text to ensure nobody thinks it is (2).

My initial misunderstanding was indeed that "direction:active" or "both" 
would imply that the c= address would be source of the connection and that 
there was precedence for this assumption.  If there is just cause to say 
that the c= address says nothing about where packets originate, then I 
would have to pick (3) above as the most robust solution that also follows 
established expectations.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: David Yon <[email-masked]>
Date: Wed, 13 Jun 2001 12:58:10 -0400

>may come from any address.

Ok, if nobody has any problem with the above, I will update the comedia 
draft accordingly and clarify that the c= line does not imply a source 
address.  In addition, I'd like to make a final proposal for how the source 
address is added to the direction attribute:

qualified-direction = direction-ident |
                         direction-ident address |
                         direction-ident address port

This essentially makes the address non-optional if the endpoint specifies a 
source port.  The rationale is that if the endpoint is able to specify a 
port it is also likely to be able to specify a source address, and if the 
endpoint felt it was necessary to specify the port then in virtually all 
cases it would also be necessary to specify the address.  I've also swapped 
the order from my first proposal---having the address come first seems more 
natural.

Thoughts?  Objections?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jun 2001 13:21:08 -0400

What you propose seems reasonable to me. But if you are going to go that
far, why not go one step further:

on the assumption that if able to supply the address then ought to be
able to specify the port as well, and that having one without the other
isn't very useful.

	Paul

---

From: David Yon <[email-masked]>
Date: Wed, 13 Jun 2001 14:21:25 -0400

Earlier in comedia's history there was the concern that some environments 
are not able to determine an ephemeral port number prior to connection.  I 
don't think it adds significant complexity to make the port always 
optional.  There may be topologies where knowing the address is sufficient 
and would allow the less flexible coding environments to work.

That said, there is currently a strong caveat in comedia in regards to 
omitting the port, and the same tone will be used for the notion of 
omitting the address.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063