Christian Hopps <[email protected]> wrote: >> I still don't really see enough explanation of: >> >> 1) what do my probe packets look like? Can I, for instance, send >> regular traffic, padded to the extra size? That's an optimistic view >> of things, but maybe appropriate. How do I get positive response that >> it was accepted? >> >> 2) How do I learn about traffic that was dropped?
> This is what https://tools.ietf.org/html/rfc8899
> <https://tools.ietf.org/html/rfc8899> documents. All that this document
> should do is provide the on the wire mechanism to send a probe packet
> and get a reply that it was received, as well as provide for not
> considering probe loss as loss events for CC (the p-bit). The CC header
> does this (the sender timestamp is echo'd back for RTT estimates). The
> implementation of RFC8899 can choose to send user data or not (RFC8899
> recommends that one should avoid doing this if possible).
I'll read again, but I am still perceiving a gap between RFC8899 and TFS.
Perhaps it is obvious to you, having designed and implemented it all over
three or four years. In reading it, I didn't understand.
As I understand it then, I have to send a AGGGRAG_PAYLOAD packet of the new
size I want to test, I include a sender timestamp in TVal, and I look for
that echoed back in the TEcho to confirm receipt. That's my PL?
I would know that it failed if I get a sender timestamp X (getting X+1),
that the oversize packet was lost.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
