Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

From: Christian Hopps <[email-masked]>
Date: Fri, 5 Mar 2021 09:16:52 -0500

> On Feb 27, 2021, at 3:14 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Christian Hopps <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
>

---

From: Christian Hopps <[email-masked]>
Date: Mon, 8 Mar 2021 04:46:01 -0500

Here's a summary of the changes based on WGLC WG mailing list discussions and reviews (published in the latest -07 document).

There were 2 minor normative clarifications/changes, clarified the intent that fragmentation should not occur over different SAs, and added a P-bit that is for external use by PLMTUD (it's unused by IP-TFS/AGGFRAG itself).

Informative changes included many editorial changes, some organizational cleanup, changing identifiers from IPTFS to AGGFRAG and making the text a bit more generic in this regard. The text on ordering packet reception as well as how extra padding can be used to avoid fragmentation was expanded. A summary section with pointers for the reciever side was added, and finally the overhead calculation was fixed in the appendix comparison data which didn't change the conclusions.

Thanks,
Chris.

P.S. A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-07

> On Jan 24, 2021, at 8:55 PM, Tero Kivinen <[email-masked]> wrote:
> 
> This is the start of 3 week WGLC on the document, ending 2021-02-15.
> Please submit your comments to the list, also send a note if you have
> reviewed the document, so we can see how many people are interested in
> getting this out.
> --
> [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>