Re: Send different fragments (of Data) together to different destinati

Mr Lee · ‎01-11-2023

I am searching for any technology / standard / protocol (for wired networks) that can help to do the following transmission scenario:

Combines many fragments of different data into one packet.
Route all fragments together through a common SPT (Shortest-Path Tree) and forward each one to a different destination.

For example, we have Data 1 (video), Data 2 (image), Data 3 (audio); F11 is the 1st fragment of Data 1, F21 (1st fragment of Data 2), F31 (1st fragment of Data 3), these fragments will be kept in Packet P1 (the 1st data packet). P1 should be as follow (if possible):

| IP header |  TCP header  |   TCP payload   |
                           +                 +
                           +                 +
                           | F11 | F21 | F31 |

Each Data / Fragment (F11, F21, F31) will be sent to their specific destinations:

Data 1 (F11) --to--> Dest 1   --
Data 2 (F21) --to--> Dest 2    |--> The destinations may not be in the same network
Data 3 (F31) --to--> Dest 3   --

--------- Update ---------

Thank you

mlund · ‎01-12-2023

I have worked with networking since 1985, I have never heard about a technology that supports that. I haven't knowledge about everything, so maybe there are something out there that supports it. But I doubt it.

Why would you like something like that? What happens for example if Data2, after it reaches the point where it should be sent to other destination, and it then get corrupted, and need a retransmission, should the original packet be sent (Data1,Data2,data3) or just the Data2, and from where.

Mr Lee · ‎01-13-2023

@mlund wrote:
I have worked with networking since 1985, I have never heard about a technology that supports that. I haven't knowledge about everything, so maybe there are something out there that supports it. But I doubt it.

Thank you.

From a point a view of a scientific researcher, is it allowed to do this customization (by referring to the image added up) regardless the performance ?

@mlund wrote:
Why would you like something like that?

It is an approach to efficiently use the bandwidth, instead of sending two or more small data (that have common routes) each time by generating more packets, they are grouped (in less packets by taking account of the available bandwidth on the path) and transmitted to their destinations. Each time the router checks the received packet and decide based on its routing table how to forward the inner fragments (collectively or separately), if separately, it will do the decapsulation of the packet.

@mlund wrote:
What happens for example if Data2, after it reaches the point where it should be sent to other destination, and it then get corrupted, and need a retransmission, should the original packet be sent (Data1,Data2,data3) or just the Data2, and from where.

Of course, only the missed / corrupted data fragment should be retransmitted from the original server (from the source).

Joseph W. Doherty · ‎01-12-2023

Not quite clear how this is going to be done as, by design, fragments use the original packet's destination address.

Or, if you did rewrite fragments' destination addresses (whether to split or combine), how do you reassemble a packet, that's fragmented, when parts of it are being sent to different destinations?

Could you explain the end-goal since mucking about with packet fragments has been a way to perform some denial of service attacks?

Mr Lee · ‎01-13-2023

Please see the following image:

@Joseph W. Doherty wrote:
Not quite clear how this is going to be done as, by design, fragments use the original packet's destination address.

I think IPv6 is a good option, it has fixed header (the first one, called "IPv6 basic header") with 40 Bytes, and an option header (comes after, called "IPv6 extension header") with variable size. I don't know if it is possible to add the destination IP addresses in the option header.

@Joseph W. Doherty wrote:
Or, if you did rewrite fragments' destination addresses (whether to split or combine), how do you reassemble a packet, that's fragmented, when parts of it are being sent to different destinations?

The data should be fragmented only by the server (the source) that takes into account the MTUs in the shortest-paths. Specific fragments are grouped together (based on their sizes) into packets and sent towards their destinations (the principle is explained in the above image), the fragments must be sent only to their destinations (referring to the above image, all fragments of Video 1 [F11, F12, F13, ..., F1n] must be received only by the user 1).

@Joseph W. Doherty wrote:
Could you explain the end-goal since mucking about with packet fragments has been a way to perform some denial of service attacks?

The goal (as I said before) is to use the free bandwidth (when available) to carry another data, and reduce the total number of packets generated.

Joseph W. Doherty · ‎01-13-2023

Ah, your follow-up postings nicely clarify. Thanks.

Originally, from just your original OP, I thought your "fragments", were specifically as IP packet fragments. Don't see that being possible.

However, slicing and dicing packets into/out-of other packets, yes, theoretically, I see what you want to do as being very possible.

Practical (especially on current hardware)? I don't believe so.

Do you understand why IP packets have a ToS byte or why tag switching (which evolved into MPLS) came to be? Both mainly to avoid a router needing to deeply analyze a packet's contents.

Have you ever seen the usual impact, to a router, which is doing current IP fragmentation? (Often a significant CPU increase, w/o even considering possible additional latency being added.)

The idea, of course, of using bandwidth more efficiently or optimally, is not new. I suspect you're aware of multicast, whose goal is to avoid needless replication of like packets. Possibly, you might be unaware of the Nagle's algorithm, which, I recall was developed to especially address the "inefficiency" of Telnet passing single characters back and forth, i.e. one character, of payload, per IP packet. (If you study Nagle's algorithm, you'll find, it's not without its own issues.)

I recall, years ago, working with some VPN product, that rather than generating a VPN packet for every original packet, it would fit as many original packets it could, into a single VPN packet. (Note - this VPN setup did have the advantage, that all the VPN packets were sourced and processed at the VPN tunnel's endpoints.) One issue I had with it, which the vendor couldn't answer, what if you combine a VoIP packet (perhaps with a ToS of DSCP EF) with some "scavenger" packet (perhaps with a ToS of DSCP CS1)? What do you set the VPN packet's ToS to?

Currently, using bandwidth efficiently/optimally has been, often, ignored, as it seems it has been easier to just being able to provide increment after increment of increased bandwidth. (E.g. Ethernet 10 Mbps => 100 Mbps => 1 Gbps = 10 Gbps, etc.)

That noted, using the least amount of bandwidth hasn't been overlooked, either. For example, you mention, in your example, using video. Well, going from MPEG2 to MPEG4 is beneficial for bandwidth saving.

Or, consider WAAS or WAFS appliances, which also further compress and/or "code" for data seen earlier, and which is cached on the far side.

So, again, to recap, could what you describe be theoretically done? I believe so. (BTW, much of my career was software development, including working down to the bit level.) Is anyone likely to pursue it, currently? I don't believe so. However, overtime technology, and needs, change. I.e. doing what you describe, currently, likely doesn't have a good enough cost/benefit ratio to pursue. But, 10 or 20 years from now? Perhaps. (With 40+ years in the industry, I've seen some interesting developments, often not predicted as to be expected in the next decade or so. Also seen many predictions, of what's going to happen in the next decade or so, not come to be.)

MHM Cisco World · ‎01-13-2023

and the fragment must keep in one router to for a time need to collect three or more fragment to build one big packet and send,
this need huge very huge buffer/memory and also with jitter and delay that will happened your user sure will claim about bad quality of server.
instead the router must as fast as send any packet even with few bytes.
this is core of good QoS.
use QoS to make video/voice to be prefer than other Data traffic.

Mr Lee · ‎01-13-2023

@MHM Cisco World wrote:
and the fragment must keep in one router to for a time need to collect three or more fragment to build one big packet and send,
this need huge very huge buffer/memory and also with jitter and delay that will happened your user sure will claim about bad quality of server.
instead the router must as fast as send any packet even with few bytes.
this is core of good QoS.
use QoS to make video/voice to be prefer than other Data traffic.

Thank you. Of course, (according to the scenario explained in the above image) the routers will not wait for the other fragments.

MHM Cisco World · ‎01-13-2023

it need to wait to first receive the three packet and then build new large packet and forward it.
that I think issue here.

Mr Lee · ‎01-13-2023

@MHM Cisco World wrote:
it need to wait to first receive the three packet and then build new large packet and forward it.
that I think issue here.

Thank you, I will keep that in mind besides other constraints (such as: headers overhead processing, maximum number of Destination IP addresses, maximum size of Data fragment/packet, ...) to search a compromise and come out with an optimal solution ---> the topic is open for any suggestion or advise.

But before that, I would like to know first if this solution is feasible (at least theoretically in the computer networking), starting by these challenges:

Could we have different fragments (of different Data) encapsulated within the TCP payload ?
Could we add more fields for Destination IP addresses in the IP packet ?

Best Regards

MHM Cisco World · ‎01-13-2023

there is some thing
if L4 push data more than the L3 can handle the L3 fragment it and with each fragment packet it add some value,
networking - IP Fragmentation and Reassembly - Stack Overflow

you can use this value for programming.

Send different fragments (of Data) together to different destinations