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... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
