Subject: Re: [Int-area] IP parcels

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 2 Feb 2022 17:58:04 +0000

Toerless, if we want the IP parcel concept to apply only for OMNI links then I
agree that we should take it up only in that document. But, if we want it to apply
for all links then we also need a standalone document that updates RFC2675
since we are changing some rules associated with the Jumbo Payload option.
I think we will want it to apply for all links.

There are benefits for all three of the source host, network path and destination
host if a parcel can be sent - even if the network path includes other links besides
just an OMNI link. But, I don't think the source host should try to send IP parcels
unless it has assurance that the destination host is prepared to accept them. So,
there are both hop-by-hop and end-to-end considerations to factor into the
equation. What do you think?

Thanks - Fred

> -----Original Message-----
> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2022 7:53 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Tom Herbert <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Int-area] [EXTERNAL] Re: IP parcels
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> On Tue, Feb 01, 2022 at 08:14:08PM +0000, Templin (US), Fred L wrote:
> > > Section 5 of draft-templin-intarea-parcels-06 reads as if there is a mandatory
> > > dependency against draft-templin-6man-omni.
> > > Q1: Is that true ? If not, then i must be overlooking a description how parcels would work
> > >     in the absence of OMNI.
> >
> > IP parcels are packets that both set a non-zero IP {Total, Payload} Length value and
> > also include a Jumbo Payload option. By RFC2675, this constitutes an illegal jumbo
> > and so it is highly unlikely that any native links (let alone native paths) would pass
> > the Parcel unless it was first encapsulated. So, encapsulation is required in any case,
> > and OMNI encapsulation is the prime example given. But, it is possible that some
> > other form of encapsulation besides OMNI might pick up on the concept.
> 
> Thanks. I would strongly suggest to improve the text so that it does not look as
> if parcels depend solely on an individual submission draft - but instead describe
> the dependencies against the underlying layer.
> 
> For once, its not clear to me if/why those parcles could not simply be passed over any
> link-layer that can support frames large enough for a parcel. Likewise, if the parcel
> needs to be hop-by-hop segmented to fit smaller link layer size, a discussion about
> the benefits and downsides of that adaption would certainly be useful for the document.
> 
> > > Q2: If there is this dependency, how do you think the parcel draft could go to
> > >     standard given how OMNI is individual submission.
> >
> > I haven't really thought about that much yet but I don't think OMNI needs to be
> > a normative dependency; some other form of encapsulation might decide to
> > pick up on the parcel concept in the future.
> 
> See above.
> 
> > > Q3: Is it possible for parcel support to only exist on an initial sequence of
> > >     subnets, and as soon as a parcel packet has to be sent out to an interface
> > >     that does not support parcels, the parcel is fragmented into normal/non-parcel
> > >     IP packets ?
> >
> > The parcel can only travel as far as the extent of the encapsulation, and once the
> > encapsulation header is removed the only choices are: 1) deliver the parcel to
> > upper layers in the case of local delivery, 2) insert a new encapsulation header
> > (i.e., re-encapsulate) and forward the parcel further, or 3) unpack the parcel and
> > forward each segment separately as an independent IP packet toward the final
> > destination.
> 
> I think your 3) is what i was asking, and i don't see this explicitly written up
> in the document.
> 
> > I had not really thought about case 3), and I will have to drop back and consider
> > whether that is something we would want to support. And, I think this only applies
> > for the final leg of the path from the decapsulator to the final destination and the
> > same logic cannot be applied for the initial leg of the path from an original source
> > to a first encapsulating node.
> >
> > What do you think?
> 
> If a path from a parcel capable source to a non-parcel capable destination could
> consist of a sequence of one or more subnets thart can carry parcels, ending in a
> router that performs 3), aka: extracting the segments and passing them on as normal
> IP packets over one or more subnets up to the final destination.
> 
> That sounds like the most obvious incremental deployment option.
> 
> 
> Btw: this where just questions i stumbled across. I still haven't gotten to the point
> of understanding what would be the benefit of parcels to existing network hops
> except if there was a clear understanding that packets >> 64kb would create some
> form of benefit for routers/network paths. But as far as i understood the document and
> discussion on the mailing list, you where primarily looking for performance benefits
> on the sending host though, not the network path.
> 
> Cheers
>     Toerless

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 2 Feb 2022 18:58:27 +0000

Toerless, I have another thought to consider. In addition to an initial end-to-end
connection handshake (e.g., a TCP option), the source host can send a "ping"
IP parcel that consists of only an IP header with a non-zero IP {Total, Payload}
Length field, a Jumbo Payload option and a single ICMP Echo Request message
body as the parcel contents. If the destination host gets the parcel, it can send
back an ICMP Echo Reply in a non-parcel IP packet. That would support a uni-
directional parcel test for the forward path only, and an analogous test would
be needed for the reverse path if IP parcels are desired in the reverse direction.

A lot can be told if the ping parcel reaches all the way to the destination. First,
it tells that the source is willing to send parcels. Second, it tells that all links on
the path are parcel-capable. And finally, if we allow the ping to carry one of Bob
and Gorry's MTU options it can also give an indication of the maximum parcel
size that can be accepted along the path.

What do you think?

Fred 

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, February 02, 2022 9:58 AM
> To: Toerless Eckert <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] IP parcels
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Feb 2022 20:06:24 +0100

On Wed, Feb 02, 2022 at 05:58:04PM +0000, Templin (US), Fred L wrote:
> unless it has assurance that the destination host is prepared to accept them.

So you are not interested in an incremental deployment option in the way i outline ?
(parcel capable sender plus some initial network subnets along the path) ?

>From my experience with IP multicast which we worked out to require hop-by-
hop end-to-end deployment (like of course IP itself) to work automatically,
partial deployment not/badly supported, i can say that you're in for a painfull slow ride
if you go this route.

Hence my question trying to understand the feasibility of incremental deployment

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Feb 2022 20:08:26 +0100

I am not at the stage of trying to work out the details of such discovery of
capabilities. I am sure it can be done. I am still stuck at understanding
what you consider to be the most easily explained benefit for the network
devices ...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 2 Feb 2022 19:35:20 +0000

Toerless, I know my response was abrupt but I will try to keep a more open mind.

Can we say that IP parcels must only be sent by the source host and not cobbled
together by a network middlebox on the path that joins non-parcel IP packets
into a group? Such a middlebox would require all of the semantics of the source
host including the host-based 5-tuple information, and would also need to receive
a series of non-parcel IP packets in the same order in which they emerged from
the source host. This sounds problematic for many networks, but perhaps not all?

But, to your point, if we allowed IP parcel forwarding to extend only up to a
network middlebox that terminates parcels then forwards individual IP packets
the rest of the way to the final destination then there would be no need for the
source and destination to have a "parcels supported" handshake. The source
can still do its "parcel ping" test to see if the network will convey parcels at
least for a certain extent of the path, then the ICMP echo request would still
reach the final destination whether as part of a parcel or as an individual IP
packet. I think it works, right?

The MTU probing would then be a different question. There would be a first
MTU (MTU1) for the portion of the path that conveys the parcel and a second
MTU (MTU2) for the remainder of the path that conveys the individual IP packets.
We would not want the MTU2 to determine the maximum IP parcel size; we
would only want MTU1 to determine parcel size. At the same time, we would
not want MTU1 to determine the Maximum Segment Size; we would only want
MTU2 to determine MSS if and only if MTU2 is less than MTU1.

Question - how can our ping test convey both MTU1 and MTU2 all the way back
to the original source?

Fred

> Sent: Wednesday, February 02, 2022 11:06 AM
> Subject: [EXTERNAL] Re: [Int-area] IP parcels
>