Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?
Dear Sir,
It is an honour to have an envigorating interaction with you and a
happy coincidence for me not to lose you, even when the chasm of
technical knowledge between us being clearly impossible to reconcile.
Of course, with my being at the receiving end.
---------- Received message ----------
From: Dan Ritter <d***g>
Date: Thu, 15 Oct 2020 06:42:45 -0400
Subject: Re: Have Debian developers contemplated means of faster
internet access, using in parallel multiple ISPs from Debian installed
Lap- /Desk- tops?
To: Susmita/Rajib <b***a@g***m>
Cc: debian-user@lists.debian.org
On 15/10/2020, Dan Ritter <d***g> wrote:
> Susmita/Rajib wrote:
... ... [snipped] ... ... [snipped] ... ...
>>
>> Sir, I apply my common sense: the CPU, memory and ports are at least 3
>> orders faster than they the signals received from individual ISPs.
... ... [snipped] ... ... [snipped] ... ...
> Yes, and this already happens. The problem is that while TCP is
> designed to be accepting of out-of-order packets, the algorithm
> it follows slows down immensely to wait for the packets to catch
> up. UDP has no such slow-down, but it also does not have a
> concept of ordering of packets, so the receiving application
> must cope with more dropped packets.
>
> The keywords to search for are "TCP window".
Yes, thanks for reminding me of the keywords and informing me on the
technicalities/complexities involved.
>> So what is essentially required is theoretically a list that keeps
>> record of time, order and port, of each of the packets requests made,
>> and rearrange the packets received from all ports according to that
>> list, to provide the system with a complete file.
>
> What happens is that the kernel keeps track of the sequence
> number embedded in each TCP packet, holds on to future packets,
> ignores repeated packets, and issues acknowledgements for each
> received packet. The sending side must detect a missing
> acknowledgement and resend the packet.
Wow! Based upon your inputs, it is surprising for me to find that
specific drawbacks/benefits indeed exist in either of TCP/IP or UDP;
what exists in the former is absent in the latter, and vice versa.
So this should give us Team GNU/Linux/Debian, both users and
developers, a scope to help each other to get rid of the difficulties
that presently exist. You create. We test and report problems.
It appears that we should indeed have a far tighter and elaborate, but
still compact, protocol and database/list for packet referencing,
i.e., port-number/packet-number/time/order, and have better chances of
improving upon data transfers and reducing packet losses. Also, with a
tight referencing, the problems in combining multiple ISPs bandwidth
to improve upon overall bandwidth shall disappear.
It appears that simply refering to packets by pure numbers, the
difficulties would become apparent as the packet-number grows larger.
So it should be better to combine UTC+'packet number' to maintain a
clear order of packets in individual systems. A virtual packet-holding
memory defined in systems to have the packets fit in their intended
places.
> As I have just pointed out, this isn't a failure in Debian or in
... ... [snipped] ... ... [snipped] ... ...
> time that people assume it is actually reliable.
Yes, a clear invitation for inventor(s)/discoverer(s).
An invitation could well be: Inventors and program writers, the arena
is yours to take over and innovate for a better protocol than TCP/IP
or UDP, having the best of either, but the worst of none.
Regards,
Rajib
Reply to: