I feel like this is going in circles.
If you have a slow link, which is what you were highlighting, you set your
re-order window to 0 -- you don't need to guard against reordering.
If you still want to detect replay attacks though, you leave your replay window
at some large number. The replay
Christian Hopps writes:
> The replay window does not need to be the same size as the reorder
> window.
But effectively it is same as there is no use of having them
different.
If my reorder window is set to 2, and my replay window is set to 1000,
if there is any reorderining happening then even w
The replay window does not need to be the same size as the reorder window.
Thanks,
Chris.
> On Apr 30, 2021, at 11:58 AM, Tero Kivinen wrote:
>
> Christian Hopps writes:
>>
>> For very slow tunnels such as your indicating, you are not worried
>> about out-of-order delivery; just set the reorde
Christian Hopps writes:
>
> For very slow tunnels such as your indicating, you are not worried
> about out-of-order delivery; just set the reorder window to 0.
We do care about the replays even when we do not care about reorder,
so setting reorder window to 0 is not acceptable, as that would
effe
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 writes:
Christian Hopps writes:
I'm not sure what
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?) m
I'm not sure what you mean by Huge delays. Given an example of a 10 kilobit
tunnel (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.
Have you considered
While reviewing the draft for publication I found out that section 2.5
says that we first reorder packets, then make sure we have not missed
any packets, and only after that we process the in-order payload
streams to extract the inner-packets.
The problem is that packet is considered lost only whe
