> On Feb 16, 2021, at 12:47 PM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: > > Signed PGP part > > Christian Hopps <cho...@chopps.org> wrote: >>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do use >>> PLMTUD? Will you tell us later in the document, or is that new work? >>> (does not look like you tell us) > >> I believed it was enough to just reference the mechanism (as we do for >> PMTUD as well). This was added during the transport area review. > > PMTUD relies on ICMP to say "too big" > > PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us that we > guessed wrong. We now have RFC8899 too, but I don't know how to apply it, > and I think that some advice is in order.
+considered the more robust option. For PLMTUD, congestion control +payloads can be used as in-band probes (see [[Congestion Control +AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]). Additionally a "P-bit" was added to the CC header so that loss of the in-band probes can be disregarded as loss-events by the CC algorithm. > I think that we need a PL defined. > >>>> The "BlockOffset" can point past the end of the "DataBlocks" data >>>> which indicates that the next data block occurs in a subsequent >>>> encapsulating packet. >>> >>> I guess, it the actual value does not matter: it's not remembered. As >>> long it is bigger than the packet, it's good. So 0xffff probably >>> works? > >> Your right it just has to point past; however, it helps to have it >> point to the exact ending when implementing (the code is easy to >> implmeent and it caught multiple bugs for me as well). > > So, then please tell us exactly what to do, and what the receiver is supposed > to pay attention to. I didn't like "can" here, for instance. ... - new data block. ~BlockOffset~ can count past the end - of the ~DataBlocks~ data in which case all the ... + new data block. If the start of a new data block + occurs in a subsequent payload the ~BlockOffset~ + will point past the end of the ~DataBlocks~ data. + In this case all the ~DataBlocks~ data belongs to + the current data block being assembled. When the + ~BlockOffset~ extends into subsequent payloads it + continues to only count ~DataBlocks~ data (i.e., + it does not count subsequent packets + non-~DataBlocks~ data such as header octets). > >>>> 2.2.2. No Implicit End Padding Required >>> >>> -- I think you are telling me that the IPv4/IPv6 length field is good >>> enough to find the end of the packet. If not, I didn't quite >>> understand. > >> You understood. > > okay, please hit me over the head harder here. Replaced this entire section (others also found it confusing) with something much simpler. +*** End Padding + +Since a data block's type is identified in its first 4-bits, the only +time padding is required is when there is no data to encapsulate. For +this end padding a ~Pad Data Block~ is used. > >>> Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' I >>> hope this will be acceptable :-) I think it's a reasonable hack, and I >>> don't see us wrapping around IP versions within a hundred years, >>> soooo... And pad blocks are "IPv0" >>> >>>> This possible interleaving of all-pad payloads allows the sender to >>>> always be able to send a tunnel packet, regardless of the >>>> encapsulation computational requirements. >>> >>> I think that you are telling me that a sender can have some pad >>> packets being created regularly (perhaps on a CPU dedicated to this) >>> and almost ready to send, and the pad packet is just replaced by real >>> data if it happens to be ready. > >> You understood perfectly. > > I think that motivating this design choice with this implementation advice is > worthwhile. > >>>> If the SA back to the sender is a non- AGGFRAG_PAYLOAD enabled SA >>>> then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used to >>>> convey the information. >>> >>> is this really worth supporting? > >> It doesn't take much to continue to allow for unidirectional use at the >> lowest layer (ESP/SA). It isn't relevant once you get to IKE where >> bidirectionality is required. > > I think that maybe this is in the MAY. > It's isn't clear to me if I need to support that or not. Greatly simplified this as well: ** Exclusive SA Use This document does not specify mixed use of an AGGFRAG_PAYLOAD +enabled SA. A sender MUST only send AGGFRAG_PAYLOAD payloads over an +SA configured for AGGFRAG_PAYLOAD use. 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
