Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #227791 > unrolled thread

Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Back to article view | Back to linux.debian.user

Contents

  Have Debian developers contemplated means of faster internet access,  using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-14 12:20 +0200
    Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-14 15:10 +0200
      Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-14 15:20 +0200
        Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-14 16:30 +0200
          Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-14 16:50 +0200
            Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 04:10 +0200
              Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-15 12:50 +0200
                Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 14:10 +0200
                  Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-15 14:40 +0200
                    Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 16:20 +0200
                      Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-15 17:00 +0200
                        Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 20:10 +0200
                          Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Dan Ritter <dsr@randomstring.org> - 2020-10-15 20:20 +0200
                            Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-16 02:40 +0200
                              Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Brett Gilio <brettg@gnu.org> - 2020-10-16 04:30 +0200
                                Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-16 05:10 +0200
                                  Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Brett Gilio <brettg@gnu.org> - 2020-10-16 05:10 +0200
                                    Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-16 06:30 +0200
          Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-10-14 17:00 +0200
            Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 03:50 +0200
    Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-14 17:00 +0200
      Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2020-10-15 03:30 +0200
      Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? Tixy <tixy@yxit.co.uk> - 2020-10-15 10:10 +0200
        Re: Have Debian developers contemplated means of faster internet  access, using in parallel multiple ISPs from Debian installed Lap- /Desk-  tops? <tomas@tuxteam.de> - 2020-10-15 10:20 +0200

Page 1 of 2  [1] 2  Next page →

#227791 — Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

To,
The Team User,
debian-user@lists.debian.org,
Debian.org

My dear illustrious Team User Leaders,

Good afternoon, leaders.

My post at the Debian Forums may please be perused here:
Faster internet access by parallelly using multiple ISPs
http://forums.debian.net/viewtopic.php?f=5&t=147081#p727593

There's a software named DISPATCH-PROXY that ostensively helps in such
opportunity:
https://github.com/alexkirsz/dispatch-proxy#readme

Has any of my illustrious team leaders used this software?

I have a query:
In debian there are many a nodejs package. If someone using Debian has
used this software with nodejs package, could i be helped please?

I tried to reach by emailing the developer Dr. Alexandre Kirszenberg,
but haven't been able to hear from him yet.

Are Debian developers planning on incorporating this program within
the DebianOS? Or any other software addressing this niche?

Could anyone help please?

Regards,
Rajib Bandopadhyay
A dedicated Debian and Knoppix user

[toc] | [next] | [standalone]

#227797 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Nicholas Geovanis <nickgeovanis@gmail.com>
Date: Wed, 14 Oct 2020 06:22:56 -0500
Subject: Re: Has Debian developers contemplated means of faster
internet access, using in parallel multiple ISPs from Debian installed
Lap- /Desk- tops
To: Susmita/Rajib <bkpsusmitaa@gmail.com>, Debian Users ML
<debian-user@lists.debian.org>

Debian has supported multiple concurrent network cards and interfaces for a
very long time. You could cable each to a separate ISP if you wish. Or all
to the same if you have the bandwidth. This is sometimes called NIC teaming.

On Wed, Oct 14, 2020, 4:48 AM Susmita/Rajib <bkpsusmitaa@gmail.com> wrote:

> To,
...		...	[snipped]	...		...	[snipped]	...		...



Dear Dr. Geovanis,
Nicholas Geovanis <nickgeovanis@gmail.com>,

I am surprised at your revelations. I have been trying to have a
breakthrough, but have been failing.

My need is a little divergant from NIC teaming  from what little I
understood after reading on the topic, after your inputs:

We have multiple USB ports in our laptops/dektops, and smartphones
with USB ports and opportunity for USB tethering and internet access
from the smartphone's mobile Network provider using SIM cards.

I wish to use two ISPs, i.e., two snartphones in USB teethering, and
combine internet bandwidth from each of the two simultaneously.

I hope that I have been able to explain myself in my post.

Regards,
Rajib Bandopadhyay
A Debian and Knoppix user

P.S.::
BTW, because of the typo "has" I have requested the List
Moderator/administrator to delete the subject thread and keep the post corrected
with "have".

[toc] | [prev] | [next] | [standalone]

#227798 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> 
> I am surprised at your revelations. I have been trying to have a
> breakthrough, but have been failing.
> 
> My need is a little divergant from NIC teaming  from what little I
> understood after reading on the topic, after your inputs:
> 
> We have multiple USB ports in our laptops/dektops, and smartphones
> with USB ports and opportunity for USB tethering and internet access
> from the smartphone's mobile Network provider using SIM cards.
> 
> I wish to use two ISPs, i.e., two snartphones in USB teethering, and
> combine internet bandwidth from each of the two simultaneously.
> 
> I hope that I have been able to explain myself in my post.

Packets have the following characteristics, at a minimum:

IP of the sender
port number of the sending process
IP of the destination
port number of the destination 

When a network interface connects to a network, it has an IP
address assigned to it. (This can be static or dynamic; it does
not matter here.) The network will only send packets that are
destined for that IP address.

An interface connecting to network A gets an address from
network A; an interface on network B has an address from network
B.

When your computer sends out a request, it can pick either
network A or network B, but the sender IP will always match the
network that it picks, and so the answer will come in on the
same network.

You have some options:

- you can pick one network as primary and the other as
  secondary, and stop using the primary if it fails.

- you can assign some of your traffic to each network, but
  answers will come back over the same network and you do not
  get an increase in bandwidth for any given session.

- you might be able to set up a proxy on a well-connected
  machine somewhere, and send all your traffic via that proxy,
  which understands that there are two paths back to you.
  However, those two paths are likely to be of different
  latencies, and you will see many exciting problems including
  out-of-order packets, dropped packets, and repeated packets.

Does this help?

-dsr-

[toc] | [prev] | [next] | [standalone]

#227799 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Dan Ritter
Date: Wed, 14 Oct 2020 09:17:25 -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 <bkpsusmitaa@gmail.com>
Cc: debian-user@lists.debian.org

Susmita/Rajib wrote:
>
...		...	[snipped]	...		...	[snipped]	...		...

Packets have the following characteristics, at a minimum:

IP of the sender
port number of the sending process
IP of the destination
port number of the destination

When a network interface connects to a network, it has an IP
address assigned to it. (This can be static or dynamic; it does
not matter here.) The network will only send packets that are
destined for that IP address.

An interface connecting to network A gets an address from
network A; an interface on network B has an address from network
B.

When your computer sends out a request, it can pick either
network A or network B, but the sender IP will always match the
network that it picks, and so the answer will come in on the
same network.

You have some options:

- you can pick one network as primary and the other as
  secondary, and stop using the primary if it fails.

- you can assign some of your traffic to each network, but
  answers will come back over the same network and you do not
  get an increase in bandwidth for any given session.

- you might be able to set up a proxy on a well-connected
  machine somewhere, and send all your traffic via that proxy,
  which understands that there are two paths back to you.
  However, those two paths are likely to be of different
  latencies, and you will see many exciting problems including
  out-of-order packets, dropped packets, and repeated packets.

Does this help?

-dsr-


Wow! Unbelievable, Dr. Ritter, but I understood your line of reasoning.

Okay, but then some questions arise:
(1)      How does "openwrt (https://openwrt.org/) able to achieve a
similar objective? If my original Debian Forums thread and posts have
been perused.

(2)      Again, how dispatch-proxy is able to achieve a similar
objective? My earlier post was here:
https://lists.debian.org/debian-user/2020/10/msg00118.html
Unfortunately, I received no reply for the post. Very well. Let us
continue to keep it dead, but use the information posted there.

Your post provides me an opportunity to clear some of my doubts, which
are endless. Etenally.

I must keep my questions very focussed so that I don't irritate or lose you.
In general, cognitive elites shall choose to ignore queries posted by
nincompoops such as I.

So, I thank you for choosing to reply to my query.

Regards,
Rajib

[toc] | [prev] | [next] | [standalone]

#227800 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> ---------- Received message ----------
> Wow! Unbelievable, Dr. Ritter, but I understood your line of reasoning.

I don't think my family has a Dr. Ritter in it, although several
of my cousins have doctorates (medical, ceramic engineering,
physics...)

> Okay, but then some questions arise:
> (1)      How does "openwrt (https://openwrt.org/) able to achieve a
> similar objective? If my original Debian Forums thread and posts have
> been perused.


Reading mwan3: Debian does it the same way, as will any other
Linux. You can connect to multiple networks, route as
appropriate, and even try outbound load balancing -- but it will
fail in the same ways on Debian as it will on OpenWRT.


> (2)      Again, how dispatch-proxy is able to achieve a similar
> objective? My earlier post was here:
> https://lists.debian.org/debian-user/2020/10/msg00118.html

It can't. It, too, will be plagued by the inability to force
inbound traffic to come to a particular interface, drop packets,
receive packets out of order, and so forth.

-- 
https://randomstring.org/~dsr/eula.html is hereby incorporated by reference.
                there is no justice, there is just us.

[toc] | [prev] | [next] | [standalone]

#227809 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Dan Ritter <dsr@randomstring.org>
Date: Wed, 14 Oct 2020 10:46:25 -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 <bkpsusmitaa@gmail.com>
Cc: debian-user@lists.debian.org

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.

In that case, multiple ports could be used apparently parallelly by
multiplexing between the Ethernet port, the WiFi port, the Bluetooth
port and at least a couple of USB ports, and 'effectively' speed up
internet signals by rearranging packets sequentially by the order the
requests were sent.

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.

So, I am indeed surprised that even with so many gifted individuals in
GNU/Linux/Debian the matter hasn't been rewritten, which should be
relatively easy to achieve, as the OS is completely modular.

Unfortunately, i didn't develop the stack of neural networks necessary
to build up such a program, otherwise, i would have done so myself and
given it to GNU.

In the end, your sense of humour to talk differently is much admired.

Regards,
Rajib

[toc] | [prev] | [next] | [standalone]

#227814 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> ---------- Received message ----------
> From: Dan Ritter <dsr@randomstring.org>
> Date: Wed, 14 Oct 2020 10:46:25 -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 <bkpsusmitaa@gmail.com>
> Cc: debian-user@lists.debian.org
> 
> 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.
> 
> In that case, multiple ports could be used apparently parallelly by
> multiplexing between the Ethernet port, the WiFi port, the Bluetooth
> port and at least a couple of USB ports, and 'effectively' speed up
> internet signals by rearranging packets sequentially by the order the
> requests were sent.

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".

> 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.

> So, I am indeed surprised that even with so many gifted individuals in
> GNU/Linux/Debian the matter hasn't been rewritten, which should be
> relatively easy to achieve, as the OS is completely modular.

As I have just pointed out, this isn't a failure in Debian or in
OpenWRT: this is the way that TCP/IP works for every device on
the Internet.

The miracle of the Internet is that it works so well most of the
time that people assume it is actually reliable.

-dsr-

[toc] | [prev] | [next] | [standalone]

#227815 — 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

[toc] | [prev] | [next] | [standalone]

#227816 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> >> 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.

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.

> 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. 

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.

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.

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.

The destruction of the packet is the second source of packet loss.

> 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 to get to
you, causing retransmissions and losses that will bring the
system to a much lower bandwidth than a single link.

As I said, you can use multiple ISPs to gain bandwidth for
multiple uses, but not for a single TCP session. 

> 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.

What we have actually works very well, and is frequently updated;
your specific use case is not supported. Sorry.


-dsr-

[toc] | [prev] | [next] | [standalone]

#227819 — 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

[toc] | [prev] | [next] | [standalone]

#227821 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> 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...

Not quite what I said. 

First off, TCP needs to run on machines which do not know what
the current time is.

Second, the TCP window is not in seconds, but in packets. 


> 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.

You should read about Bufferbloat. It turns out that excessively
large packet caches make everything worse.

https://tools.ietf.org/html/rfc8289 CoDEL against Bufferbloat

Rajib, I understand that you are frustrated and looking for
solutions. The particular solutions you are proposing are not
going to work. You are reasoning by analogy, which is good for
solving many human problems, but in this case we have computer
problems, and they need to be solved by looking at the actual
protocol documents and implementation history, so that you can
understand what is actually happening.

https://tools.ietf.org/html/rfc793   TCP

https://tools.ietf.org/html/rfc7414  The 2015 TCP roadmap
    - you should especially read sections 3 and 4.

Perhaps it is time to look at what your original problem is, in
the hopes of solving that?

-dsr-

[toc] | [prev] | [next] | [standalone]

#227830 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Dan Ritter <d***g>
Date: Thu, 15 Oct 2020 10:54:29 -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]	...		...
>
> You should read about Bufferbloat. It turns out that excessively
> large packet caches make everything worse.
>
> https://tools.ietf.org/html/rfc8289 CoDEL against Bufferbloat

Sure, Sir. I shall go through this doc and the rest

> Rajib, I understand that you are frustrated and looking for
> solutions. 	...		...		...		...	

Sir, actually I am not frustrated, but am indeed looking for a
breakthrough, of increasing bandwidth. In fact, I am bubbling with
positive energy, wanting things to improve, if I find even a little
ray of opportunity.

> ...		...	The particular solutions you are proposing are not
> going to work. You are reasoning by analogy, which is good for
> solving many human problems, 	...		...		...	

But Sir, I have a living example in openwrt and routers based on it.
Also dispatch-proxy as a crude first step. And they work for multiple
ISPs and VPN. If they could do it, then why not GNU/Linux including
Debian? We could have software routing devices using our computers
instead of those exotic routers.

> 	...		...		...	but in this case we have computer
> problems, and they need to be solved by looking at the actual
> protocol documents and implementation history, so that you can
> understand what is actually happening.
>
> https://tools.ietf.org/html/rfc793   TCP
>
> https://tools.ietf.org/html/rfc7414  The 2015 TCP roadmap
>     - you should especially read sections 3 and 4.

Yes Sir, perhaps it is time that I did.

> Perhaps it is time to look at what your original problem is, in
> the hopes of solving that?

In fact Sir, I have no problem with any particular ISP, but I have
multiple number of them, including Optical Fibre to the Home, ADSL
through copper cable and mobile networks, and want to use them
simultaneously. It was a brainwave that I had because of the existent
serverless distributed downloading like Bittorrent and p2p file
transfer mechanisms.

If it could be done with p2p and bittorrent, then why not with server
based systems and multiple ISPs? This was my line of reasoning.

Anyway, thank you for engaging with me. Let's see if something positve
comes out of this interaction, or seeds some breakthroughs in some
specific stack of Neural Nets not necessarily mine. Sometimes I lament
that I didn't learn computing as a university course. But that is
_only_ sometimes. I am perfectly content with HEP physics and all of
you around me. My little needs are already fulfilled by Debian and
Knoppix.

Regards,
Rajib

[toc] | [prev] | [next] | [standalone]

#227831 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

Susmita/Rajib wrote: 
> ---------- Received message ----------
> 
> > ...		...	The particular solutions you are proposing are not
> > going to work. You are reasoning by analogy, which is good for
> > solving many human problems, 	...		...		...	
> 
> But Sir, I have a living example in openwrt and routers based on it.
> Also dispatch-proxy as a crude first step. And they work for multiple
> ISPs and VPN. If they could do it, then why not GNU/Linux including
> Debian? We could have software routing devices using our computers
> instead of those exotic routers.

Openwrt is Linux.

The thing that you are asking for: Openwrt does not do it.

To the extent that Openwrt does it; Debian does it just as well.
Which is to say, badly.

> In fact Sir, I have no problem with any particular ISP, but I have
> multiple number of them, including Optical Fibre to the Home, ADSL
> through copper cable and mobile networks, and want to use them
> simultaneously. It was a brainwave that I had because of the existent
> serverless distributed downloading like Bittorrent and p2p file
> transfer mechanisms.
> 
> If it could be done with p2p and bittorrent, then why not with server
> based systems and multiple ISPs? This was my line of reasoning.

That's not what you asked at the beginning.

You asked if it was possible to gang together several wireless
networks from disparate ISPs in order to get one super-fast
connection. That is not possible, for the reasons we have now
gone into in depth.

If what you want is multiple ISP connections operating
simultaneously, with different sessions using different
connections, so that no individual session will use more than
one ISP but the aggregate bandwidth is used, that is relatively
easy.

https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html

So, to improve the quality of discussion in future:

always describe your actual problem, not a contrived example.

-dsr-

[toc] | [prev] | [next] | [standalone]

#227838 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Dan Ritter <d***g>
Date: Thu, 15 Oct 2020 14:16:52 -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:
>> ---------- Received message ----------

> That's not what you asked at the beginning.
>
> You asked if it was possible to gang together several wireless
> networks from disparate ISPs in order to get one super-fast
> connection. That is not possible, for the reasons we have now
> gone into in depth.

I am still asking for that. Just that I am not restrained by what
exists and what doesn't. There isn't a restriction that what doesn't
exist today won't exist tomorrow. In other words, I am looking for
creators/inventors who would re-write the way data is transferred over
the internet.

> If what you want is multiple ISP connections operating
> simultaneously, with different sessions using different
> connections, so that no individual session will use more than
> one ISP but the aggregate bandwidth is used, that is relatively
> easy.

No Sir, I just cited an example/analogy.

Having studied physics I have come across many epoch-making twists
when established mathematicians of their eras have been dethroned by
new experiments and subsequently new invention/discoveries.

I continue to remember that we are only slightly evolved irrational
animals and we justify stupidities all the time just to maintain the
status quo, our mundane jobs or just petty agenda. So I don't let the
established norms restrain my imagination. Only that this is not my
primary field of operation.

May be, someone bright and just right from somewhere shall reach the
topic and do things in a way that others have missed.

I shall continue to draw them to the existing challenges /
opportunities that exist.

Best wishes and regards.

Rajib

[toc] | [prev] | [next] | [standalone]

#227840 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

"Susmita/Rajib" <bkpsusmitaa@gmail.com> writes:
> Having studied physics I have come across many epoch-making twists
> when established mathematicians of their eras have been dethroned by
> new experiments and subsequently new invention/discoveries.
>
> I continue to remember that we are only slightly evolved irrational
> animals and we justify stupidities all the time just to maintain the
> status quo, our mundane jobs or just petty agenda. So I don't let the
> established norms restrain my imagination. Only that this is not my
> primary field of operation.
>
> May be, someone bright and just right from somewhere shall reach the
> topic and do things in a way that others have missed.
>
> I shall continue to draw them to the existing challenges /
> opportunities that exist.
>
> Best wishes and regards.
>
> Rajib
>

Can we keep the smarter than thou 'art noise to a minimum? This is the
debian-users list, not the Fields Medal acceptance ceremony.

-- 
Brett M. Gilio
brettg@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

[toc] | [prev] | [next] | [standalone]

#227842 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

👍
No offence or hurt intended. But could have inadvertently caused.
Sincerely apologise.
So far as I am concerned I have temporarily put the thread to rest.
Regards,
Rajib


---------- Received message ----------
From: Brett Gilio <b***g>
Date: Thu, 15 Oct 2020 21:27:44 -0500
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: Dan Ritter <d***g>, debian-user@lists.debian.org

"Susmita/Rajib" <b***m> writes:
...		...	[snipped]	...		...	[snipped]	...		...

Can we keep the smarter than thou 'art noise to a minimum? This is the
debian-users list, not the Fields Medal acceptance ceremony.
...		...	[snipped]	...		...	[snipped]	...		...

[toc] | [prev] | [next] | [standalone]

#227843 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

"Susmita/Rajib" <bkpsusmitaa@gmail.com> writes:

> So far as I am concerned I have temporarily put the thread to rest.

Stay well, these are hard times. We only have each other.

Best

-- 
Brett M. Gilio
brettg@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

[toc] | [prev] | [next] | [standalone]

#227844 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

On 16/10/2020, Brett Gilio <b***g> wrote:
> "Susmita/Rajib" <b***m> writes:
>
>> So far as I am concerned I have temporarily put the thread to rest.
>
> Stay well, these are hard times. We only have each other.
>
> Best
...		...	[snipped]	...		...	[snipped]	...		...

Thank you, Dr. Gilio. Wish the same for us all.
Regards
Rajib

[toc] | [prev] | [next] | [standalone]

#227802 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

[Multipart message — attachments visible in raw view] — view raw

dispatch-proxy only works with HTTP and Socks. Any other protocol will be
untouched at its layer. Openwrt is for embedded network equipment. I cant
verify this yet, but I believe they have completely rewritten the network
stack.
So each does their load balancing and proxying in completely different ways
than you will.

On Wed, Oct 14, 2020, 9:21 AM Susmita/Rajib <bkpsusmitaa@gmail.com> wrote:

> ---------- Received message ----------
> From: Dan Ritter
> Date: Wed, 14 Oct 2020 09:17:25 -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 <bkpsusmitaa@gmail.com>
> Cc: debian-user@lists.debian.org
>
> Susmita/Rajib wrote:
> >
> ...             ...     [snipped]       ...             ...     [snipped]
>      ...             ...
>
> Packets have the following characteristics, at a minimum:
>
> IP of the sender
> port number of the sending process
> IP of the destination
> port number of the destination
>
> When a network interface connects to a network, it has an IP
> address assigned to it. (This can be static or dynamic; it does
> not matter here.) The network will only send packets that are
> destined for that IP address.
>
> An interface connecting to network A gets an address from
> network A; an interface on network B has an address from network
> B.
>
> When your computer sends out a request, it can pick either
> network A or network B, but the sender IP will always match the
> network that it picks, and so the answer will come in on the
> same network.
>
> You have some options:
>
> - you can pick one network as primary and the other as
>   secondary, and stop using the primary if it fails.
>
> - you can assign some of your traffic to each network, but
>   answers will come back over the same network and you do not
>   get an increase in bandwidth for any given session.
>
> - you might be able to set up a proxy on a well-connected
>   machine somewhere, and send all your traffic via that proxy,
>   which understands that there are two paths back to you.
>   However, those two paths are likely to be of different
>   latencies, and you will see many exciting problems including
>   out-of-order packets, dropped packets, and repeated packets.
>
> Does this help?
>
> -dsr-
>
>
> Wow! Unbelievable, Dr. Ritter, but I understood your line of reasoning.
>
> Okay, but then some questions arise:
> (1)      How does "openwrt (https://openwrt.org/) able to achieve a
> similar objective? If my original Debian Forums thread and posts have
> been perused.
>
> (2)      Again, how dispatch-proxy is able to achieve a similar
> objective? My earlier post was here:
> https://lists.debian.org/debian-user/2020/10/msg00118.html
> Unfortunately, I received no reply for the post. Very well. Let us
> continue to keep it dead, but use the information posted there.
>
> Your post provides me an opportunity to clear some of my doubts, which
> are endless. Etenally.
>
> I must keep my questions very focussed so that I don't irritate or lose
> you.
> In general, cognitive elites shall choose to ignore queries posted by
> nincompoops such as I.
>
> So, I thank you for choosing to reply to my query.
>
> Regards,
> Rajib
>
>

[toc] | [prev] | [next] | [standalone]

#227808 — Re: Have Debian developers contemplated means of faster internet access, using in parallel multiple ISPs from Debian installed Lap- /Desk- tops?

---------- Received message ----------
From: Nicholas Geovanis <ni***is@gmail.com>
Date: Wed, 14 Oct 2020 09:57:41 -0500
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@gmail.com>, Debian Users ML
<debian-user@lists.debian.org>

...		...	[snipped]	...		...	[snipped]	...		...
> 	...		...	 Openwrt is for embedded network equipment. I cant
> verify this yet, but I believe they have completely rewritten the network
> stack.
> So each does their load balancing and proxying in completely different ways
> than you will.
>
> On Wed, Oct 14, 2020, 9:21 AM Susmita/Rajib <bkpsusmitaa@gmail.com> wrote:
...		...	[snipped]	...		...	[snipped]	...		...

Yes Sir, it appears then that i have understood the situation better
than i had considered possible. In that case, it really bothers me
that such gifted programmers and developers at Debian/GNU/Linux in
general' weren't inspired by the idea to implement it within the OS,
given that we all have more than one USB port, one BT and one WiFi
channel free most of the time.

Had i the gift, i would surely have written the stack by myself, like
Dr. Torvalds did. But alas!

However, Mr. Andrei Popescu has given me some links and I could use
them in this case.

Regards,
Rajib

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web