What is the metric and why a programmer should care ? - networking

Question

It's my understanding that by "metric" or "metrics" we describe the length ( in bytes right ? ) of a package traveling over the network, the problem is that as far as I know this value it's ISP related and it's almost impossible to find even 2 ISP with the same metric.

If I'm programming a P2P software to keep 2 software synced, and I would like to estimate what is the optimal size for my packets, does it makes sense to keep metrics in the count especially due to the fact that is an ISP related value and in the entire world there are a lot of ISPs ? I should apply some "heuristic algorithm" like assuming that the best metric is the lowest one and I just keep adding empty values for the padding on the longest one ?

Thanks.

PS if you need a starting point for an example I would prefer something in C++ since i'm interested in this language at the moment.

EDIT: a recap of the comments that you can find down below: looks like my question is too generic and now I'm focusing on MTU and latency ( lag ) to keep things more straight to the point.

Answer 1

Networking (and in particular inter-networking) is a relatively young science, not yet completely formed. Hence not all the "right behavior" is "shared" by anyone, simply because there are not all believing (or forced) to rein it "right". The consequence is that anyone must -at some level- "care" of anything since it is never possible to have a full trust.

That said, to come close to your problem, let me start by telling you that you are yourself "unstrusted" since you use improper terminology.

You speak about networking "metric" (something, that, in networking science is related to routing) but you talk about something else, that is the MTU (Maximum Transfer Unit). If you speak to a network engineer that way, you almost sure you'll never find the answer to your question, simply because he will most likely understand another completely unrelated thing.

Now that everything is clear (I hope), lets understand a little bit of theory:

• Every transmission media, because of its very physics, introduce some errors.
  • At the link level this is mainly due to "electric noise" or to group dispersion, that makes the "signal" less and less intelligible.
  • At a circuit (or path, for connection-less network protocol, like IP) level this can be due packet loss due to congestion.
• The immediate consequence of the above points is that "an infinite end-to-end correct transmission" is not physically possible".
• To take care about this, both link protocols as well as transport protocols have to introduce some "redundancy check" (CRC) and some mechanism -in case the checksum fails- to recover the error. In this sense, the MTU is just the maximum number of bytes you can push into a packet without violating the underlying rules about how CRC are computed and the physical media managed.
• Depending on the application needs, IP offers different "transport protocols":
  • UDP is a "don't care": if a packet gets lost, the transport protocol will do nothing to recover
  • TCP is a "Full care, until a given time limit": if something gets lost, a retransission will be asked. All this is managed at the TCP/IP driver level, so the application is not required to take care, unless the "problem" last more than the timeout limit of a session.
• Independently on the TCP and UDP behavior, IP offer also a "fragmentation": if a transport unit is too long to fit a link protocol frame, the packed is split into more smaller ones. This process happens (at least in theory) at every hop (every time you traverse a router to go from one link to another and another and another up t the final destination) and requires a complete reconstruction of the packet structure and CRC, hence it require more computational time and CPU power or routers that it will be normally required to just move a packet from port to another.

And this is why you have to take care: network performance are not the same for whatever packet length: longer packets into TCP requires less "waiting for acknowledge" time (so data transfer can flow faster), but longer packets requires longer latency in case of intermediate fragmentation, and more processing power on routers. (at the point that many ISP don't fragment: if it cannot go, they just discard, and let TCP to re-tune to a smaller MTU, or to the application to shorten its UDP packets).

In other word, if you don't care about performance, Just let TCP do do its job, and the data will somehow find a way to flow (by an intermediate fragmentation or by a and-to-end MTU negotiation). But if you want to maximize the performance, the less error-control-and recovery mechanisms you "stimulate" the less latency you get, and hence the more wide "segments" you get and hence the higher data rate you get.

There is an "optimal length" for every path you can have between the two endpoints you have to discover and respect if you want better performance.

If you use UDP, things are a bit worst: since there is no MTU negotiation and recovery, if a too long packet gets discarded along the way (because at a certain point it will no more fit a physical media, and the ISP is not going to fragment, to protect himself and other clients) you have to take care, and reduce its size, otherwise you will never be able to transfer it.

Feel free to retain the ISP is "unfair" to you, but consider that an excess of fragmentation activity can sit a router at the point no other transmission is possible from nowhere to no-one. And this is a damage higher than simply drop you flow.