A DDoS works by making a system running out of a scarce resource. What happens then depends on the resource that is exhausted.
For instance, the resource may be CPU. The attackers send many requests, and the server must spend some CPU resources to respond to these requests. When the load augments, the server begins to respond slower, then becomes sluggish, then takes so much time to respond that it becomes practically unusable. However, in that case, the server kernel is still perfectly able to handle network activity, and may connect to external systems without any problem. The code running on the server itself will have pretty little CPU to work with (e.g. if there are 500 concurrent threads crying out for CPU time, the code will have 1/500th of the normal machine abilities) but this can be sufficient, depending on what you are trying to do with that connection.
When the resource is network bandwidth, things will be harsher for your extra outgoing connection. A "saturated network" means that at least one of the directions for the network flow ("download" or "upload", from the server point of view) is too full of packets to accommodate extra packets on a timely basis. However, a TCP connection requires packets in both direction, right from the connection establishment (the "three-way handshake") and throughout the lifetime of the connection (since all bytes must be acknowledged).
If you want your outgoing connection to proceed while the wires are saturated, you need QoS: a way to "tag" your packets in such a way that involved routers know that these packets get priority. This can be done in several ways; in particular, you may instruct routers to send in priority packets related to a specific port number (you would do that with port 22, to allow SSH traffic to and from your Web server, even when the Web server drowns under heavy port-80 packets).
Possibly, you could configure routers to consider an outgoing connection as being more important than incoming traffic, but this is tricky: a router can decide that a given connection is "outgoing" only if it saw the initial packets, and remembers them. Once the connection is established, it is bidirectional and symmetric; there is no longer a "client" and a "server", only two machines that talk to each other. If routers have to remember things, then you have just added another scarce resource (RAM on routers) that may become subject to DDoS.
A crucial point is that your server is not alone in a case of network DDoS: the few links and routers "close" to your server (in the network path) also suffer from the same attack. This means that if you want to implement QoS, then you need to do it on several routers, from your server to the "big infrastructure" (which is here assumed to be un-DoSable, by virtue of being big). You cannot reliably fix that by tweaking only your server; network DDoS are an infrastructure concept, which must be solved at the infrastructure level.