[Int-area] Call for comments of the draft Service Routing in MEC

[duzongp...@foxmail.com]

Hi, all

We have recently proposed a new version of the draft  
https://datatracker.ietf.org/doc/draft-du-intarea-service-routing-in-mec/ 

And we introduced it in the last meeting.

We are glad that anyone who is interested in can give some suggestions. 
Thanks.

Abstract   This document introduces a service routing mechanism in the 
scenario
   of Multi-access Edge Computing, which can bypass the DNS procedure.
A slide is also available:

https://datatracker.ietf.org/meeting/114/materials/slides-114-intarea-service-routing-in-multi-access-edge-computing-ietf114-00


Thanks to the comments of EV in the meeting. And I will send it to the 
v6ops as well.


Best Regards
Zongpeng Du



duzongp...@foxmail.com & duzongp...@chinamobile.com
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Tom Herbert]

On Mon, Aug 1, 2022 at 9:51 AM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:

> Juan Carlos and intarea, there is actually much more to be said about this
> from a “big-picture”
>
> standpoint that has not been said yet. In particular, the AERO/OMNI and IP
> Parcels architecture
>
> uniquely enable fast and efficient large object transports in conjunction
> with small-message
>
> interactive communications requiring low latency. It does this by allowing
> large MTU links
>
> (9KB or larger) in edge network data centers while requiring small MTU
> links (9KB or smaller)
>
> in the core transit network. In that way, end systems can send large
> objects in IP Parcels that
>
> take advantage of the larger edge network link MTUs, but become fragmented
> when they
>
> reach an OMNI link ingress node. The fragmentation allows the IP parcel to
> transit the core
>
> network where there are small MTU links, but without interfering with
> interactive small message
>
> communications also transiting the core due to fragmentation interleaving.
> Then, at the far
>
> end the final destination which may also be located in an edge network
> having large MTU
>
> links can efficiently receive the larger IP Parcels.
>
>
>
> This has been known for many decades, but perhaps not widely discussed.
> Back in 1988
>
> when the DECnet architects were bringing FDDI into the architecture, then
> even had a name
>
> for it and called it the “dumbbell configuration” (FDDI in edge networks
> and Ethernet core):
>
>
>
>
>
> So, in this dumbbell model, peer end systems located in the rightmost and
> leftmost FDDI rings
>
> could send IP Parcels up to 4500 bytes and the Ethernet link ingress and
> egress nodes would
>
> fragment and reassemble. The core would therefore see only 1500 byte and
> lesser with fair
>
> sharing interleaving between both bulk transfer and interactive
> communications. Replace the
>
> Ethernet link in the above diagram with a network of networks and
> configure an OMNI
>
> interface over it, and the same effect can be had using AERO/OMNI and IP
> Parcels.
>

Hi Fred,

It's not really the same thing. Presumably, at the ingress each 4500 byte
packet would be fragmented and could be serially sent over a PTP Ethernet
link. This makes reassembly at the egress side fairly trivial since one
could assume that all the fragments are received in proper order with no
fragments for other flows mixed in. So the egress side only needs a 4500
byte reassembly buffer.

However, you replace the Ethernet in the picture with an IP network, then
these simplifying properties no longer apply. The egress side may receive
fragments out of order, and there may simultaneously may be multiple flows
in reassembly. So the required memory for reassembly is greater than 4500
bytes, possibly much greater than that. Also, since this is not a PTP link,
packets for a flow may take different paths such that reassembly never
completes and  hence timers are required to punt on reassembly.


>
> This would make for a better and more efficient internetworking service
> for all supporting
>
> a diversity of services ranging from delay-sensitive interactive
> communications to short
>
> transactions, to high data rate binary large object transfers with the
> best properties applied
>
> according to traffic type. It is good for the Internet, therefore
> AERO/OMNI and IP Parcels
>
> are good and should be adopted.
>

As I and others have pointed out, performing reassembly in the network is
costly to routers (i.e. cost in memory at least) and difficult to get right
otherwise (e.g. many edge conditions, trade offs between a non
work-conserving opportunistic optimization and tail case latency). If you
remove in-network reassembly from the proposal, there is still potential
for "intelligent" fragmentation in the network where losing a fragment
doesn't mean losing the whole packet, but it's not clear to me that the
benefits for that outweigh the costs.

Tom


>
>
> Fred
>
>
>
> *From:* Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Templin
> (US), Fred L
> *Sent:* Friday, July 29, 2022 6:44 AM
> *To:* Juan Carlos Zuniga (juzuniga) ;
> int-area@ietf.org
> *Subject:* Re: [Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
>
>
> FYI, a new draft version is posted with the following updates:
>
>
>
> 1) Senders encodes the number of segments included in the Jumbo Payload
> header so receivers
>
> can accurately determine packaging sizes.
>
>
>
> 2) Excuses OAL intermediate nodes from having to perform parcel
> sub-dividing or re-combining.
>
>
>
> Fred
>
>
>
> *From:* Int-area [mailto:int-area-boun...@ietf.org
> ] *On Behalf Of *Juan Carlos Zuniga (juzuniga)
> *Sent:* Thursday, July 28, 2022 11:00 AM
> *To:* int-area@ietf.org
> *Subject:* [EXTERNAL] Re: [Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
>
>
> EXT email: be mindful of links/attachments.
>
>
>
>
> Hi all,
>
>
>
> As mentioned during 

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

[Templin (US), Fred L]

Juan Carlos and intarea, there is actually much more to be said about this from 
a “big-picture”
standpoint that has not been said yet. In particular, the AERO/OMNI and IP 
Parcels architecture
uniquely enable fast and efficient large object transports in conjunction with 
small-message
interactive communications requiring low latency. It does this by allowing 
large MTU links
(9KB or larger) in edge network data centers while requiring small MTU links 
(9KB or smaller)
in the core transit network. In that way, end systems can send large objects in 
IP Parcels that
take advantage of the larger edge network link MTUs, but become fragmented when 
they
reach an OMNI link ingress node. The fragmentation allows the IP parcel to 
transit the core
network where there are small MTU links, but without interfering with 
interactive small message
communications also transiting the core due to fragmentation interleaving. 
Then, at the far
end the final destination which may also be located in an edge network having 
large MTU
links can efficiently receive the larger IP Parcels.

This has been known for many decades, but perhaps not widely discussed. Back in 
1988
when the DECnet architects were bringing FDDI into the architecture, then even 
had a name
for it and called it the “dumbbell configuration” (FDDI in edge networks and 
Ethernet core):

[cid:image001.png@01D8A58A.8FD01BC0]

So, in this dumbbell model, peer end systems located in the rightmost and 
leftmost FDDI rings
could send IP Parcels up to 4500 bytes and the Ethernet link ingress and egress 
nodes would
fragment and reassemble. The core would therefore see only 1500 byte and lesser 
with fair
sharing interleaving between both bulk transfer and interactive communications. 
Replace the
Ethernet link in the above diagram with a network of networks and configure an 
OMNI
interface over it, and the same effect can be had using AERO/OMNI and IP 
Parcels.

This would make for a better and more efficient internetworking service for all 
supporting
a diversity of services ranging from delay-sensitive interactive communications 
to short
transactions, to high data rate binary large object transfers with the best 
properties applied
according to traffic type. It is good for the Internet, therefore AERO/OMNI and 
IP Parcels
are good and should be adopted.

Fred

From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin (US), 
Fred L
Sent: Friday, July 29, 2022 6:44 AM
To: Juan Carlos Zuniga (juzuniga) ; 
int-area@ietf.org
Subject: Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10

FYI, a new draft version is posted with the following updates:

1) Senders encodes the number of segments included in the Jumbo Payload header 
so receivers
can accurately determine packaging sizes.

2) Excuses OAL intermediate nodes from having to perform parcel sub-dividing or 
re-combining.

Fred

From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Juan Carlos 
Zuniga (juzuniga)
Sent: Thursday, July 28, 2022 11:00 AM
To: int-area@ietf.org
Subject: [EXTERNAL] Re: [Int-area] Call for WG adoption of 
draft-templin-intarea-parcels-10


EXT email: be mindful of links/attachments.




Hi all,

As mentioned during the meeting, we will close the call at the end of the IETF 
114 week.

If you have any last comments, please speak up.

Best,

Juan Carlos & Wassim

From: Int-area mailto:int-area-boun...@ietf.org>> on 
behalf of Juan Carlos Zuniga (juzuniga) 
mailto:juzuniga=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 22, 2022 at 2:26 PM
To: int-area@ietf.org 
mailto:int-area@ietf.org>>
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

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)

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area