Hi Peter,

When I talk with system administrators at universities or schools, they complain about three thing usually: bandwith, bandwith, bandwith. *g* To be more precise, they complain about:
a) the huge amount of bandwith used to transfar files (Gnutella is used to download large files, MP3s, movies, software etc), this is a up to a few hundred MBs/day per every user running a Gnutella client in the internal network.
b) the constant backbone traffic used to keep up the Gnutella network (routed searchqueries and search results), this is a constant few KB/s for every user running a Gnutella client in the internal network, summarized up to a few MBs/h 24/7, even when not downloading any file or being away from your PC. A local reflector (inside the internal network, also used as gateway for the internet) could reduce this to a minimum.
Bandwith costs money, so P2P system are not very liked from system amdinistrators. Btw, they usually do not complain about potential copyright abuse or RIAA lawsuits.

No, Gnutella traffic is between hosts running Gnutella software.
It happens that Gnutella clients tries to reach a peer after it has gone offline (perhaps it will come back or is only temporarily away). Together with dynamic IPs it happens that someone sees an incoming Gnutella connect attempt (port 6346/6347 usually) without ever running a gnutella client. Ignore it, it's just a knock at the wrong door. Unfortunatly some bad/old clients try hammering old peers for a longer time, I think you can call this misbehaviour flooding (but it's not eaten up bandwith, it's just anoying). However this is an issue for further improvements, perhaps some Gnutella clients could evalute TCP/IP error codes better.

You might forgot that other common internet protocolls use TCP too (e.g. http, ftp, smtp)? TCP is just a transportation layer (see OSI-layer) and provides usefull features also for gnutella. Perhaps I misunderstood your question? When you mean that the gnutella network should be orientated at the underlying ISP network, you're right! This is an issue for future improvements IMHO. Here is a repost from an older thread:
Another interesting approach to reduce traffic was not mentioned here so far: Host caches or super peers with a regional toplogy and multicast, to reduce ISP traffic. While gnutella backbone causes huge traffic for ISPs, traffic should not be reduced inside gnutella network only but also for the underlying physical network. Not reducing this huge ISP traffic, means slower network performance and increasing costs for ISPs. This could mean for the enduser (us) increased internet costs or more expensive flat rates.

Hope I could help a little bit. Greets, Moak

PS: TruStar, Gnutella protocoll v0.6 is not developed by Limewire, it's devloped by many free developers and volunteers together (e.g. meet a bunch of them at the_GDF). Actually LimeWire does a lot of valuebale research for the Gnutella community and is one of the pushing force, but I will never understand the marketing reason of naming superpeers 'ultrapeers' or jumping over protocoll version 0.5. :-) Links to protocoll specification could be found in the sticky thread in the Developer Forum here.