I understand your thinking there, but it is generally a good idea to give the suppport folks what they ask for even if you don’t see a reason for it; in this case a traceroute is a simple enough request and, if it helps them eliminate a possible source fo the problem, providing it is time well spent.
I realize that you are “connecting” without problem, but with transfers that large, taking that long, and at that speed, lots of things can happen along the route between your box and the ftp server that can, and often do interrupt the transfer. That is one of the reasons many of the linux distros now only distribute their iso’s via bittorrent - it’s more robust for largish transfers. And your transfers are "largish, to say the least. I’d also be suspicious of your cable provider jumping into what it sees as a very long continuous stream of outgoing data from your box, and if you haven’t contacted them about the problem you are having, you should. Unless you are monitoring the route carefully, and checking for packet loss during the extended upload period, you can’t really assume it’s a DH problem (though it very well may be).
It’s pretty easy to tell that you are frustrated, but you might do well to realize that moving multi-gigabyte files via an 32kbs upload link is not a trivial task across a distributed network; any router along the way that “craps”, “burps” or takes a few minutes to respond or reset could be contributing to the probelm…and during the extended transfers, there is a lot of opportunity for that to happen.
As for what to do, as I said before, I do not know the answer to your problem. I suspect that it will take some significant investigation involving the whole transfer process before anyone is likely to determine authoritatively what is causing the behavior. That said, and since you immediate goal is to successfully complete the transfers, I suggest you do what the military does when having transmission problems…break the transmission into smaller packets.
You can use tools on your computer to “split” those monster files into smaller chunks for transfer (only small enough to transfer successfully) and then use the linux shell to “reassemble them” into their original “monster sized” state once all the "chunks have been received.
I don’t know what system you are using at your end, but there are loads of such tools that have *nix counterparts…you just need to locate a tool that will “split” files in a way that an appropriate *nix tool (DH uses Debian linux) can reassemble, and you have a workaround until the problem is identified and resolved or for another time when network condition, sunspots, the position of the stars, or whatever other “voodoo” interferes with one of your massive transfers.
I’m not saying it’s ideal, but it is a “tried and true” way of dealing with such gremlins when it is more important to get the files transferred than it is to track down the source of the problem…
This is the first time I noticed you mentioning the size of the files you are having trouble with; moving that size files over a consumer-grade ISP account is likely to continue to give you periodic problems. That , unfortunately, is the state of consumer-level connectivity in the United States at present. And I know that sucks, but don’t shoot me for pointing it out - I’m just the messenger.