Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10

["Templin (US), Fred L" <[e-mail]>]

Richard, I am finally returning to answer your questions from much earlier on in
this thread. See below for responses:

Thanks - Fred

1. The text “multiple upper layer protocol segments” is ambiguous. It seems that you really mean “multiple segments from ‘the same’ upper layer protocol”, doesn’t it? It seems that multiple segments from different upper layer protocols are not allowed in your parcel.
>Yes, that is correct – multiple segments from the same ULP 5-tuple.

2. Is the following a fair statement? All segments in the same packet come from the same application identified by the 5-tupe (source address, destination address, source port, destination port, protocol number).
>Yes, that is a fair statement. It does say this clearly in the draft at one point; were there other
> points in the draft where it did not seem so clear?

3. Segment size
You require that their sizes be the same except for the last one. Is this required for easy implementation or what? Do you require it for any other reasons?

>Having all segments except the final one be the same size is what makes many aspects of the
> proposal even possible in the first place. By having a same segment size, there is no need to
> carry an offset field for telling where the segments belong during reassembly. But, that is just
> one aspect – there are many others.

4. TTL issue
You described how parcels are forwarded over the Internetwork, and in particular you described what the ingress/egress middlebox does about parcels. I understand that the ingress middlebox may break the parcel into smaller ones, which may rejoin at the egress middlebox. My question is about TTL. As different smaller parcels may traverse along different paths, as a result their TTLs may be different when they reach the egress middlebox . How does the egress middlebox set up the TTL value? Please provide more descriptions.

>If a middlebox reassembles multiple smaller parcels into one larger parcel, it should use the
> minimum TTL received in any of the smaller parcels when it constructs the one larger one.
> The draft is silent on this point, and should probably be updated.

5. Reordering at the egress middlebox
The parcels would arrive one after another, and therefore the egress middlebox would “wait” for a little bit to identify and pick up enough parcels/packets for their rejoining and repackaging. A description of the egress middlebox behavior would be useful and helpful, in particular I would like to know more about the waiting time if any, and how you deal with the reordering and loss.

>First, the egress middlebox is likely to be very close to the destination or an end
> middlebox for the destination. The egress middlebox could simply allow the sub-
> parcels to flow through to the end system without attempting any reassembly
> at the parcel level (or with only partial reassembly at the parcel level) and it will
> work fine.

6. IPv4 option
Does IETF still allow to change/add IPv4 option fields? I might be wrong, but aren’t they frozen? Also, do commercial routers still care about IPv4 options?

>The IP parcels proposal reuses the RFC1063 “MTU Probe” option which is deprecated by RFC1191.
> This puts to good use an existing number.

7. IPv6 option
This draft has defined a hop-by-hop option, it will require every intermediate IPv6 router to inspect this option. There have been some discussions on the pros/cons about Hop-by-Hop IPv6 Option. Is there any feedback from WG 6man?

>Most IPv6 routers will never see this hop-by-hop option because it will be encapsulated
> in another IPv6 header that will be seen by IP layer forwarding devices as having no
> options. Only adaptation layer forwarding devices will see the HBH option, and there
> will be very few of those on the path.

8. Parcel Path Qualification
This draft has described a method for parcel path qualification probe from end to end. It is nice to have it, but it is unreliable simply for the following reason: a probe parcel goes along one specific path, and your real application parcels may take different paths.

>This shouldn’t be a problem if the path probe uses the same upper layer protocol 5-tuple
> as ordinary data packets. The probe should instead flow through the same path as ordinary
> data packets will take.

9. Integrity
First paragraph of Section 7. More explanation/elaboration should be useful. I might have missed it in previous paragraphs, but if I do, please provide a reference to it such as “as described in …”.

>I will see if I can improve the text in the next draft version.

10. Implementation Status
In section 10. TSO’s performance gain and Parcel’s gain should be regarded as two different things. Since this draft is adding a hop-by-hop option, every intermediate router is required to process the hop-by-hop option, which will, theoretically speaking, lead to performance downgrade. Of course, the whole performance would depend on many other factors, such as the total numbers of routing table lookups and number of segments.

>This work is very closely related to GSO/GRO and TSO/TRO and designed to work hand-in-hand
> with them. About HBH options slowing down processing, this will not be a problem because the
> HBH options will not even be seen by the large majority of routers in the path most of the time
> due to encapsulation.

11. General observation
This proposal essentially tries to solve a problem caused by MTU. If MTU be very big, one would simply put the whole data in a single packet. Since MTU is limited, a packet has to be cut into many smaller pieces (segments). In the existing specification, when an intermediate router sees a packet with its size larger than MTU, the router would be expected to fragment it so that the fragments could be forwarded. Here let me call it “fragmentation as needed”. In reality, however, some (if not all) commercial routers don’t do “fragmentation as needed”, instead of fragmenting the packet they simply discard it in order to achieve the wire-speed. This draft defines a new way to address the MTU issue: when a router sees a packet with its size larger than MTU, the router is asked to fragment it in a prescribed way (fragment it into pre-packaged segments). If I may, let me call it “fragmentation as prescribed”. Both “fragmentation as needed” and “fragmentation as prescribed” would require the support from intermediate routers. As the same as fragmentation as needed, fragmentation as prescribed may downgrade the performance of intermediate routers. What is more, intermediate routers/boxes may perform “rejoining and repackaging”, which will adversely impact the performance of the intermediate routers/boxes.

>A couple of things already mentioned – fragmentation and reassembly will be invisible to the
> large majority of intermediate IP routers on the path. Also, we need to evolve an understanding
> that the segment size selected by upper layer protoocls (e.g., TCP, users of UDP, etc.) need not
> be bounded by the path MTU – in some cases, using a segment size smaller than the path MTU
> will result in better performance, while in other cases a segment size larger than the path MTU
> may be better.

From: Int-area [mailto:[e-mail]] On Behalf Of Richard Li
Sent: Friday, July 01, 2022 3:11 PM
To: Juan Carlos Zuniga (juzuniga) <juzuniga=[e-mail]>
Cc: [e-mail]
Subject: Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10

Chairs and Authors,

I always like every new idea and effort to improve the Internet performance, and thus I have read this draft with a great interest. The following are my observations/comments/questions. If they don’t make any sense to you, please accept my apology, and disregard them.

1.      The text “multiple upper layer protocol segments” is ambiguous. It seems that you really mean “multiple segments from ‘the same’ upper layer protocol”, doesn’t it? It seems that multiple segments from different upper layer protocols are not allowed in your parcel.

2.      Is the following a fair statement? All segments in the same packet come from the same application identified by the 5-tupe (source address, destination address, source port, destination port, protocol number).

3.      Segment size
You require that their sizes be the same except for the last one. Is this required for easy implementation or what? Do you require it for any other reasons?

4.      TTL issue
You described how parcels are forwarded over the Internetwork, and in particular you described what the ingress/egress middlebox does about parcels. I understand that the ingress middlebox may break the parcel into smaller ones, which may rejoin at the egress middlebox. My question is about TTL. As different smaller parcels may traverse along different paths, as a result their TTLs may be different when they reach the egress middlebox . How does the egress middlebox set up the TTL value? Please provide more descriptions.

5.      Reordering at the egress middlebox
The parcels would arrive one after another, and therefore the egress middlebox would “wait” for a little bit to identify and pick up enough parcels/packets for their rejoining and repackaging. A description of the egress middlebox behavior would be useful and helpful, in particular I would like to know more about the waiting time if any, and how you deal with the reordering and loss.

6.      IPv4 option
Does IETF still allow to change/add IPv4 option fields? I might be wrong, but aren’t they frozen? Also, do commercial routers still care about IPv4 options?

7.      IPv6 option
This draft has defined a hop-by-hop option, it will require every intermediate IPv6 router to inspect this option. There have been some discussions on the pros/cons about Hop-by-Hop IPv6 Option. Is there any feedback from WG 6man?

8.      Parcel Path Qualification
This draft has described a method for parcel path qualification probe from end to end. It is nice to have it, but it is unreliable simply for the following reason: a probe parcel goes along one specific path, and your real application parcels may take different paths.

9.      Integrity
First paragraph of Section 7. More explanation/elaboration should be useful. I might have missed it in previous paragraphs, but if I do, please provide a reference to it such as “as described in …”.

10.   Implementation Status
In section 10. TSO’s performance gain and Parcel’s gain should be regarded as two different things. Since this draft is adding a hop-by-hop option, every intermediate router is required to process the hop-by-hop option, which will, theoretically speaking, lead to performance downgrade. Of course, the whole performance would depend on many other factors, such as the total numbers of routing table lookups and number of segments.

11.   General observation
This proposal essentially tries to solve a problem caused by MTU. If MTU be very big, one would simply put the whole data in a single packet. Since MTU is limited, a packet has to be cut into many smaller pieces (segments). In the existing specification, when an intermediate router sees a packet with its size larger than MTU, the router would be expected to fragment it so that the fragments could be forwarded. Here let me call it “fragmentation as needed”. In reality, however, some (if not all) commercial routers don’t do “fragmentation as needed”, instead of fragmenting the packet they simply discard it in order to achieve the wire-speed. This draft defines a new way to address the MTU issue: when a router sees a packet with its size larger than MTU, the router is asked to fragment it in a prescribed way (fragment it into pre-packaged segments). If I may, let me call it “fragmentation as prescribed”. Both “fragmentation as needed” and “fragmentation as prescribed” would require the support from intermediate routers. As the same as fragmentation as needed, fragmentation as prescribed may downgrade the performance of intermediate routers. What is more, intermediate routers/boxes may perform “rejoining and repackaging”, which will adversely impact the performance of the intermediate routers/boxes.


Best regards,

Richard



From: Int-area <[e-mail]<mailto:[e-mail]>> On Behalf Of Juan Carlos Zuniga (juzuniga)
Sent: Wednesday, June 22, 2022 12:25 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10

Dear IntArea WG,

We are starting a 2-week call for adoption of the IP-Parcels draft:
https://www.ietf.org/archive/id/draft-templin-intarea-parcels-10.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-templin-intarea-parcels-10.html&data=05%7C01%7Crichard.li%40futurewei.com%7C715b5db213134932c70208da5484f702%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637915227299598680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=w4G5ypaSRv%2FR31%2F%2B857XT2xUqHdEXv90ubD5GGjqBEQ%3D&reserved=0>

The document has been discussed for some time and it has received multiple comments.

If you have an opinion on whether this document should be adopted by the IntArea WG please indicate it on the list by the end of Wednesday July 6th.

Thanks,

Juan-Carlos & Wassim
(IntArea WG chairs)