[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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-


Reply to: