Is rerouting possible in UDP?

Question

So I am trying to understand routing for TCP and UDP segments. I have a couple of things that I am confused about:

• In TCP, is there any specification on how many packets would be dropped before a rerouting would be done for a connection established between two end-systems?
• In UDP, is rerouting even possible? If a specific route keeps losing a lot of data, will the two parties ever transmit data using another route, because there is never a connection establishment phase. So how is it ever going to be possible to establish another route between the two parties if ever a communication link goes down somewhere. How is the route decided for UDP in general i suppose would be a well placed question?

Thank you for your answers in advance.

Answer 1

This is not the hosts that decide which route a packet will follow, each router in the path make it's own decision.

(Actually, the originating host could use the IP strict source option to try to force the packets to go through a specific route, but it's rarely, if ever, used, and it's totally ignored by routers on the Internet.)

So each router can change the route of packets depending on the network condition (link drop, congestion on a link, load balancing...)

What a host can decide is to alter it's TCP window (flow control), to modify the rate at which it sends information, but this doesn't impact routing.

Except for Policy Based Routing, routing is a layer 3 decision that doesn't take into account layer 4 (TCP / UDP) information, so it's performed in the same way for TCP / UDP / ICMP etc...

Answer 2

I guess you are getting confused between the responsibilities of IP & transport layer.

It is the responsibility of IP layer to decide the routes of each packet depending on the congestion and other factors. Any transport layer protocol doesn't guarantee of the path that will be taken by all packets of a given connection.

But the thing TCP ensures is that since it is connection oriented hence if some packets got missing or lost it will resend them to the other host which is missing in UDP since it does not track packet loss using method like sequencing.

Answer 3

Alright: you cannot have an answer here which does not even mention the word "IP" once. I need to fix that... The important stuff is in the first section, you can skip the Motivation sections if you are short on time.

The onion (OSI model)

Let me make this very clear: When talking about networking, it is fundamental that you start thinking in layers. In the case of the internet, this means the OSI model:

• Layer 5, 6, 7: session, presentation, application (in short: application stuff).
• Layer 4: Transport; Segment (TCP) / Datagram (UDP); Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing.
• Layer 3: Network; Packet (here: "Internet Packet" or "IP"); Structuring and managing a multi-node network, including addressing, routing and traffic control.
• Layer 2: Traffic between two nodes (here we have MAC addresses and such, that is, Ethernet).
• Layer 1: Physical bits and pieces (cables, electric protocols, but also WLAN radio waves and low level encryption).

(3 and 4 copied from Wikipedia, the rest shortened as it is not relevant here.)

While, in theory, you could use any layer in routing decisions, the OSI model (at least up to and including level 4, above which things become a bit foggy) is not some theoretical CS construct, but absolutely practical and "real". The term "routing" is firmly attached to layer 3, and it does happen, for all intents and purposes, and exceptions nonwithstanding, on layer 3. That means: IP packets are routed. We neither route Ethernet frames nor TCP or UDP connections.

TCP/IP is routed the same as UDP/IP because neither TCP nor UDP plays any role. Usually; it is only the "/IP" part that is relevant here. If there is any distinction, it is whether the protocol is TCP or UDP as such (for example: if you are playing an online game and it uses UDP, you might decide to send all your UDP to some separate low latency link instead of your high latency bulk link), not whether an individual IP belongs to an individual TCP or UDP stream.

Motivation (abstract)

For a motivation: think about when you browse a Wikipedia or Stack Exchange page. Your browser does not only request one ressource, but dozens or even hundreds per page (little images, CSS, javascript files and whatnot). Assume they all come from the same server (and assume your browser does not support keep-alive for HTTP requests), then in the worst case there will be dozens of individual TCP/IP connections between your PC and the HTTP server. It would make no sense at all for a router to decide to route on layer 4 (i.e., to route the traffic based on which individual TCP/IP stream they belong to) - all those TCP/IP connections share the same source and destination, and it makes much more sense to only look at individual IP packets. This means that if, for example, the best route for that traffic changes inmidst you downloading a very large page, all the IPs can be routed another way, instead of a fixed route for any given TCP/IP stream.

Another example would be a TCP/IP connection like a shell session. Let's say you open it at morning and keep it open until the night (and assume there is no timeout/auto-logout feature...). Then it would be totally useless if you were somehow forced to use the same route all those hours; it would be much more useful to be able to decide for each packet, say if an intermittent failure knocks out a certain path for a while.

Motivation (technical)

Also, high bandwidth routers have their hands full with loads (sic) of things, even if they look only at IP and not higher layers. Big routers are already very expensive, and it is really not an easy job they are doing.

Now, if you would want to keep track of TCP connections, you would introduce an additional kind of stream-based state to the routing decisions. While there may or may not be routing algorithms out there that do so, you can imagine that for the usual case, it would serve no purpose whatsoever to take on this additional CPU and RAM burden on some anonymous router somewhere in the wild of the 'net. There might be some useful applications if your application is closely coupled to the actual router sitting in front of you, but that would be an extremely special case.

That is why we have packet based switching/routing in the first place, amongst others: we fully accept, nay, demand, that there needs and usually can be no fixed path between source and destination. In the past, static routed algorithms needed to keep track of the route for each connection; this is not so anymore.

So even if there may be some exception to the rule and even if you do find some advanced router that has some way to influence IP routing based on their TCP or UDP payload, for the vast majority of existing routers/networks you will not find such. And if you do, those TCP based features are more likely to be used as intrusion detection (i.e., more like a firewall) or closer to a proxy than for pure routing purposes. And even then, you will likely find that they are doing their connection inspection stuff while not caring about routing at all.

Answer 4

The transport layer (TCP/UDP) does not decide which route a packet takes. And the sending host only decides where to send the packet for the first hop. Often there is only one option for the first hop, in which case the sending host doesn't get to decide anything.

However if Equal-cost multi-path (ECMP) routing is being used, the sender can try to influence the path a packet will take by varying the fields inspected by ECMP. Usually that means retry the connection using a different source port number.

If you are using Multipath TCP (which must be supported by both endpoints before you can use it) different underlying combinations of IP and port number will be attempted which can give you higher throughput and better resilience to failing network links.

I know of no way to achieve the same with UDP. Protocols on top of UDP can build their own ways to influence routing decisions. For example if a DNS request receives no answer a client could retry with a different source port number which may cause the packet to take a different route.

There is also the possibility for ECMP to include flow label as discussed in RFC 6438. Using that it could in principle be possible for the sender to change routing decisions without the need to change IP or port number. However changing flow label for an existing connection could potentially cause breakage in other ways.

Answer 5

From the perspective of the router, a packet is a packet is a packet. It will route based on availability of routes to the intended destination, if there are many possible routes, the packets could be sent in many possible routes, and arrive in a different order than they were sent in. This is referred to as Packet Switching. It's the job of higher level layers to reassemble those packets in the correct order. That is where the differences between UDP and TCP come into play.