> On Feb 27, 2021, at 3:14 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > 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?
Correct. > I would know that it failed if I get a sender timestamp X (getting X+1), > that the oversize packet was lost. Correct. Thanks, Chris. > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
