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
I now closed the WG adoption call and marked this document as adopted
by WG. There were some comments requested during adoption call, and I
would hope authors would process those and submit next version of the
draft as WG document.
When I was myself checking the document I noticed that it referes
