For very slow tunnels such as your indicating, you are not worried about
out-of-order delivery; just set the reorder window to 0.
FWIW, the interest we are aware of is for 1GE to 100GE general purpose tunnels.
Thanks,
Chris.
Tero Kivinen <kivi...@iki.fi> writes:
Christian Hopps writes:
I'm not sure what you mean by Huge delays. Given an example of a 10
kilobit tunnel
10 kilobytes not kilobits, i.e. about 80 kilobits/s. This can handle
several low quality audio connections inside, or one high quality
uncompressed cd-quality mono channel.
(really?) means *everything* is super slow, so then
reporting raw wall clock times is a bit disingenuous I think. I
didn't actually look over the math b/c this just doesn't seem
realistic.
I do not really consider useful to waste bigger bandwidth for single
audio connection or similar, and I would assume audio connections is
one of those uses cases where proper TFC is useful.
Another use case could be terminal connection between servers (text
based ssh), I mean I can't really read xterm faster than one kilobytes
per second, so this provides 10 times the bandwidth needed for normal
terminal connection. I regularly have terminal connections between my
devices which lasts for weeks, and I would rather hide the fact when I
am actually using them, when I am not using them, but I do not want to
allocate tens of % of my home network bandwidth just for that case. 1%
would probably be acceptable (100 kilobits/s from the 10 megabits/s
inbound connection my VDSL offers).
Filetransfers, videostreams etc are not that interesting in the TFC
point of view, as they often try to use almost all bandwidth there is
(i.e., video stream will use as high quality than what your network
connection allows), and those usually have less of privacy concerns.
Have you considered what happens to your inner TCP stream bandwidth
when you have regular packet loss, regardless of IPTFS? I think a
slight bursty-ness given regular packet loss is the least of your
problems at that point.
Audio quite often uses UDP. Terminal connections do use TCP, and I do
regularly use SSH connections from all over the world to my home
server using RTT of 200-300 ms, and you do easily notice couple of
second delays when TCP looses packets. Now, when there would be
several seconds more just because TFC that would be even more
annoying.
What kind of bandwidth allocation you would do for audio connection
between two end-points? Lets say doorbell audio connection from your
door to your home over the mobile phone network? You might not want to
outsiders to notice when there is traffic between the gate and home,
or even when you start listening the sound from the gate...
Also note, that re-ordering and replay window size must be bigger than
largest re-ordering time, and sometimes when there are multiple
network links involved with bufferbloat etc, those times can be
measured in seconds, thus having replay window size of few seconds is
not unexpected configuration. This just mean that if you use 100
kbytes/s, i.e., 1 mbit/s bandwidth the replay window size will not be
32, it will be 256 packets, and if you use one megabyte / per second
bandwidth it will be 1000 packets etc. I think the 32 packets window
size is the minimal setting people use...
Of course, as I have been mostly working on the IoT environments and
standards lately my view of world is IoT centric, but those devices
are one of the devices which could benefit from the better security...
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
