2

As I understand, TCP packets in a TCP session can take any path in the world to their destination, the path each takes depends on the routing tables of the routers it passes through, resulting in some packets taking different paths to others (other OSI layers/network factors are involved of course). My network admin professor stated that SSL establishes a "static" (or whatever you want to call it) data pipe, so that all packets take the same route as the initial. I can't find anything to support this, is it correct?

If so, does any other protocol suite (or whatever) create similar session "pipes" through routers? And can they work for UDP?

This all leads to a concept for UDP static data pipes for more consistent WAN performance, due to my widely varied experience with online games and latency/packet loss inconsistency. Is it being done now? How might I achieve this for my own software?

Improve this question
4
  • Ideally I was hoping to be able to use a process that creates multiple static data "pipes" or "tunnels", tests each for latency, packet loss and other factors, and based on those results pick the one to proceed with. I don't need to see/know the path, just that it exists. And encryption, error checking, etc, is already handled by other protocols such as SSL. If it could be done, there are drawbacks like how it affects dynamic routing changes, but hopefully would allow for more stable connections when used. Commented Oct 6, 2015 at 8:11
  • I'm not sure what you're trying to accomplish. All the "pipes" from A to B will take the same path unless there is a topology change. So each one will have the same latency, etc. Also remember the "pipes" are one-way. That is, the return path may be (and often is) different than the forward path. Commented Oct 6, 2015 at 13:27
  • @RonTrunk I understand what you mean, in theory dynamic routing is best for sure. In reality I'm seeing a lot of packet loss and wild latency variations (jumping from 100 to 350 or more). Although now I'm suspecting congested connections and overloaded buffers are the culprit. Commented Oct 6, 2015 at 16:05
  • The problem is that routing decisions rarely use link utilization as a metric. So all your traffic will still flow through a congested link -- and there's not much you can do about it. Commented Oct 6, 2015 at 16:08

4 Answers 4

Reset to default
2

SSL can be routed in different ways for each different packet in the same way as any other non-ssl traffic. The routing takes place at a different layer of the stack than the encryption and still relies on the same mechanism for deciding routes for individual packets in a stream.

By definition the Internet's WAN is packet switched for all protocols - only at a point to point level, or for non-IP networks, can you define protocols that don't switch at the packet level.

Improve this answer
0
1

I'm going to assume you misunderstood what your professor said. Routers forward packets at layer 3, so they don't "know" whether the data is TCP, UDP, or anything else.

They also don't maintain any information about previous packets, so every forwarding decision is made independently. So packets to the same destination can take different paths.

Improve this answer
2
  • Nope, That's exactly what he said. Commented Oct 5, 2015 at 15:28
  • 1
    If that's the case, then I'm afraid he's (or she's) wrong about that. You can consider it a static logical pipe, but packets can the different paths to the destination. Commented Oct 5, 2015 at 15:30
0

UDP itself is used when the information does not need to be consistently received on the receiver's end. The reason most gamers feel udp is a far better protocol is primarily down to the game's handling of out of sequence information and/or the use of programming techniques that hides udp ...

Short udp joke there ....

In other words if you can tolerate inconsistent data, and this is primarily the case with a large networked set of players where the player with the largest network issues has the commands conveniently ignored while the rest of the game world proceeds, then udp might be it for you.

Improve this answer
1
  • haha ...... joke. I understand TCP/UDP and an ok amount of the SSL process. The theoretical idea here isn't about the encryption or packet order, it's about the destination being X hops away and suddenly 80% of traffic is going around the world instead, being totally dropped, or my ISP's aggregate link being totally unreliable. Commented Oct 5, 2015 at 16:08
0

The short answer is, there's no way of knowing where your packets are routed to. On the one hand you're pretty sure peering agreements of the isp means you can be certain of where the next hop destination will be, but after that, the next-next is not guaranteed. This was the only way you could get guaranteed connectivity on what is essentially a mix of networks without a direct connection to the destination server. You can also contrast it to uucp and smtp where you could specify the intermediate hosts through which your mail could be transmitted between. Since those are not l3 based, it fulfills the conditions of strictly routing through known hosts, but at the same time allowing unfettered packet travel.

It is also of interest to note every other technology that comes layered above L2/L3 routing considerations is meant to solve characteristics caused by this dichotomy.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.