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-
Reply to: