Christian Hopps <cho...@chopps.org> 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 <mcr+i...@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to