As far as I'm aware, sure you can. TCP packets and UDP datagrams are wrapped in IP datagrams, and it's the job of an IP network to ship your data from point A (sender) to point B (receiver). Nodes along the way might do so-called "deep packet inspection" to snoop on the payload of your IP datagrams (for various reasons, not all nefarious), but they don't need to do that to do the basic job of routing. From a semantic standpoint, the information in the TCP and UDP headers (as part of the IP payload) is only there to govern interactions between the two endpoint parties. (For instance, the "port" of a TCP or UDP packet is a node-local identifier for one of many services that might exist at the IP address the packet was routed to, allowing many services to coexist at the same node.)

▲

HPsquared a day ago | parent | next [-]

Huh. So it's literally "TCP over IP" like the name suggests.

▲

stavros a day ago | parent | prev [-]

Hmm, I thought intermediate routers use the TCP packet's bits for congestion control, no? Though I guess they can probably just use the destination IP for that.

	▲	dilyevsky an hour ago \| parent \| next [-]
		TCP congestion control is performed by the end device based on mostly packet drop feedback. Middleboxes just drop traffic. Though sometimes there are techniques such as AQM (active queue management) where middleware router sends a special ECN (exlicit congenstion notification) bit in the packet but then still that relies on both endpoints to support and respect that notification.
	▲	toast0 16 hours ago \| parent \| prev \| next [-]
		Most intermediate routers don't care much. Lookup the destination IP in the routing table, forward to the next hop, no time for anything else. Classic congestion control is done on the sender alone. The router's job is simply to drop packets when the queue is too large. Maybe the router supports ECN, so if there's a queue going to the next hop, it will look for protocol specific ECN headers to manipulate. Some network elements do more than the usual routing work. A traffic shaper might have per-user queues with outbound bandwidth limits. A network accelerator may effectively reterminate TCP in hopes of increasing acheivable bandwidth. Often, the router has an aggregated connection to the next hop, so it'll use a hash on the addresses in the packet to choose which of the underlying connections to use. That hash could be based on many things, but it's not uncommon to use tcp or udp port numbers if available. This can also be used to chose between equally scored next hops and that's why you often see several different paths during a traceroute. Using port numbers is helpful to balance connections from IP A to IP B over multiple links. If you us an unknown protocol, even if it is multiplexed into ports or similar (like tcp and udp), the different streams will likely always hash onto the same link and you won't be able to exceed the bandwidth of a single link and a damaged or congested link will affect all or none of your connections.
	▲	Twisol a day ago \| parent \| prev [-]
		They probably can do deep/shallow packet inspection for that purpose (being one of the non-nefarious applications I alluded to), but that's not to say their correct functioning relies on it. Those routers also need to support at least UDP, and UDP provides almost no extra information at that level -- just the source and destination ports (so, perhaps QoS prioritization) and the inner payload's length and checksum (so, perhaps dropping bad packets quickly). If middleware decides to do packet inspection, it better make sure that any behavioral differences (relative to not doing any inspection) is strictly an optimization and does not impact the correctness of the link. Also, although I'm not a network operator by any stretch, my understanding is that TCP congestion control is primarily a function of the endpoints of the TCP link, not the IP routers along the way. As Wikipedia explains [0]: > Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. [0]: https://en.wikipedia.org/wiki/TCP_congestion_control