Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?
Kind Sir,
I went through your entire message very carefully. Some areas you had
already mentioned. Some were indeed new to me! Some I knew.
But carefully reading through your message, I failed to find this part
of my Email addressed:
[Quote]
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 ...
[/Quote]
(Where UTC is Universal Time Coordinated) which you say is already in
place. Then the idea of "TCP window" would have been non-existant...
Next:
[Quote]
... A virtual packet-holding
memory defined in systems to have the packets fit in their intended
places.
[/Quote]
This part must surely need improvement. Otherwise, restrictions of
data transmission speeds over multiple ISPs would have been
non-existent.
---------- Received message ----------
From: Dan Ritter <d***g>
Date: Thu, 15 Oct 2020 08:35:43 -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***m>
Cc: debian-user@lists.debian.org
On 15/10/2020, Dan Ritter <d***g> wrote:
> Susmita/Rajib wrote:
... ... [snipped] ... ... [snipped] ... ...
> This is because TCP is designed to be a reliable long-term transport over
> an unreliable medium, and UDP is designed to be an unreliable,
> short-term transport over the same unreliable medium.
>
> A web page is generally brought to you by TCP; a DNS request is
> usually handled with UDP.
... ... [snipped] ... ... [snipped] ... ...
> Sadly, this is not the case.
>
> A TCP session is identified by four parts:
>
> sender IP
> sender port
> receiver IP
> receiver port
>
> and sequence numbers are maintained for each session. There is
> no confusion involved.
This part is remembered.
> There are two primary sources of packet loss. The first is
> ordinary signal decay. This does not happen much over local
> wired or optic connections, but happens relatively often over
> long wire connections, and happens appallingly frequently over
> any radio connection, such as WiFi, GSM, or LTE. There's not
> much we can do about this other than note that it exists and
> plan for it.
Partially known, although i'd assumed that WiFi and LTE were better
than GSM(2G).
> The second source of packet loss is an overloaded forwarding
> device - a switch, router, or media converter with mismatched
> speeds - and here a useful analogy may be employed:
>
> The Internet is a series of railroad tracks. For the purposes of
> this analogy we will pretend that they are flawless transports:
> whatever you load in at one end will be received at the other
> end. Each packet you put in is whisked along the track to the
> next station, where the inspector reads the destination address
> and determines what to do with it: put it on the best available
> path, put it on a siding waiting for the best available path to
> be ready, or destroy it. If the packet goes to the best
> available path, it is now the next inspector's problem. If the
> packet goes to a siding, it may be put on the right path soon,
> but if the siding fills up, it will be destroyed.
Yes, this part was nebulously known.
> The destruction of the packet is the second source of packet loss.
Yes, this part is obvious. Known. But overcome by re-requesting multiply.
>> Also, with a
>> tight referencing, the problems in combining multiple ISPs bandwidth
>> to improve upon overall bandwidth shall disappear.
>
> I'm afraid not. The packets will take different paths ...
"Different paths" is known.
> ... The packets will take different paths to get to
> you, causing retransmissions and losses that will bring the
> system to a much lower bandwidth than a single link.
This needn't necessarily be, with virtual packet-holding memory
allotted, usually perhaps observed in multi-session file downloaders
and bittorrent applications. Also, the 3rd order higher speeds of
processors, ports and memory must be remembered.
> As I said, you can use multiple ISPs to gain bandwidth for
> multiple uses, but not for a single TCP session.
Yes, true, a single log-in to log-out internet session involves
multiple TCP sessions with SYN, FIN and RST packets and multiple files
transfers. So the idea of having multiple ISPs to parallelly run for
file transfers remains very feasible.
> What we have actually works very well, and is frequently updated;
> your specific use case is not supported. Sorry.
Please don't give up your contemplation. Kindly pay more attention to
the attendant issue. You and all programmers.
Kindly take some time and reconsider. Please.
Regards,
Rajib
Reply to: