Subject: Re: [IPsec] iptfs publication request

From: Christian Hopps <[email-masked]>
Date: Mon, 04 Oct 2021 04:10:53 -0400

Hi Tero,

Will you be able to provide the text changes that would cover the issue you have? Would really like to get this submitted to IESG before another IETF cycle completes.

Thanks,
Chris.

Christian Hopps <[email-masked]> writes:

> It was resolved with the transport area by adding the drop timer. I
> added more text to highlight and even recommend the drop timer in the
> latest revision, but it is apparently not enough.
>
> I believe Tero really wants to allow for sending packets as soon as
> he can, even if it means complexity in the implementation (keeping 1/
> 2 processed outer packets around), I believe this is unneeded, but
> see no reason to disallow it either — and certainly not to block the
> document.
>
> I’m just asking Tero to provide text that will make him happy, rather
> than keep going around and around with me not getting the text
> correct.
>
> Thanks,
> Chris.
>
>
>
>     Paul
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Oct 2021 13:21:21 -0400

Christian Hopps <[email-masked]> wrote:
    > Will you be able to provide the text changes that would cover the issue
    > you have? Would really like to get this submitted to IESG before
    > another IETF cycle completes.

I also would like to see exactly what the difference is.
I also would like the document submitted to the IESG.
(And the IESG has become even more active, so it could still take many
revisions to get to publication)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 31 Oct 2021 20:36:39 +0200

Christian Hopps writes:
> Will you be able to provide the text changes that would cover the
> issue you have? Would really like to get this submitted to IESG
> before another IETF cycle completes. 

How about following:
----------------------------------------------------------------------
2.5.  Summary of Receiver Processing

   An AGGFRAG enabled SA receiver has a few tasks to perform.

   The receiver SHOULD process incoming AGGFRAG_PAYLOAD payloads as
   soon as they arrive as much as it can. I.e., if the incoming
   AGGFRAG_PAYLOAD packet contains complete inner packet(s), receiver
   should extract them and forward them immediately. For partial
   packets the receiver needs to keep the partial packets in the
   memory until the they fall out from the reordering window, or until
   the missing parts of the packets is received, in which case it will
   reassemble them and send them out. If AGGFRAG_PAYLOAD payload
   contains multiple packets they SHOULD be sent out in the order they
   are in the AGGFRAG_PAYLOAD (i.e., keep the original order they were
   received on the other end).

   Instead of the method described in the previous paragraph the
   receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received
   into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3),
   and only after it has in-order AGGFRAG_PAYLOAD payload stream,
   receiver extracts the inner-packets. In this case the receiver
   considers a packet lost when it's sequence number is abandoned
   (e.g., pushed out of the re-ordering window, or timed-out) by the
   reordering algorithm. Using this methold will make sure the packets
   are sent in-order, i.e., there is no reordering possible, but the
   cost is that any lost packet will cause delay of full reorder
   window, and there will be extra burstiness in the output stream
   (when lost packet is dropped out from the re-order window, all
   outer packets received after that are then immediately processed,
   and sent out back to back).

   Additionally, if congestion control is enabled, the receiver sends
   congestion control data (Section 6.1.2) back to the sender as
   described in Section 2.4.2 and Section 3.
----------------------------------------------------------------------

I think that captured what I proposed long time ago to you in several
emails, but now this is full section so it should be easier to
incorporate than the earlier proposed separate sentences.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 15:53:07 -0400

> How about following:

works for me.