lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: lee.e.rian at census.gov (lee.e.rian@...sus.gov)
Subject: TCP / IP


D B <geggam692000@...oo.com>wrote:
>
> I am just a student learning about TCP/IP and dont
> know where to post this idea,

comp.protocols.tcp/ip would probably be better
http://groups.google.com/groups?hl=en&lr=&group=comp.protocols.tcp-ip


> figured posting it here
> would get me some flames and links.
>
> Why not make the window the size of the file to be
> transmitted and the ack back have the segments missing
> thereby reducing overall overhead and lag time.

sounds like you re-invented selective ack.  Take a look at RFC 2018
http://www.rfc-editor.org/rfcsearch.html


> ie
>
> host1 1mb file --- sent -- > host2
>
> host1 <-- ack missing 3 6 8 segments -- host2
>
> host1 -- segments 3 6 8 sent ---> host2
>
> host1 <-- FIN --- host2
>
>
>
> The window could be dynamic according to content size.
>
> Buffers would have to be huge but with RAM so cheap
> these days why not ?

RAM may be cheap but no matter how much you have, it's still a finite
resource; eventually you will fill up the buffers.  And even if the buffers
are sufficiently large that you don't fill them up you run into problems of
queueing time.  With sufficiently large buffers packets can sit in the
output queue longer than the sending hosts' retransmit timeout value.  Slow
start is a Good Thing :-)


> or am I smoking newbie crack ?

nah - good ideas

Regards,
Lee


> Dan






Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ