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-
