On Fri, Sep 7, 2018 at 10:46 AM, Arashmid Akhavain <arashmid.akhav...@huawei.com> wrote: > 100% Agree with you Tom. And these are type of questions we need to answer > when we talk about GTP replacement. The control plane in today's mobile core > sets up the tunnel and ensure the uniformity of QoS in > both forward and backward path.
Hi Arashmid, FAST should be orthogonal to the issue of GTP replacement and is agnostic to underlying RAN protocols. It's implemented at the IP layer and the network services it conveys can be supported by a network in an arbitrary fashion. > > Can you elaborate on using FAST? FAST on UPFs? The basic idea of FAST is that hosts (UE) requests tickets from a "ticket agent" in their local network. The request is an abstract description of desired services (like low latency, low jitter for 1080p video chat). The ticket agent sends back a "ticket" that encodes the services the network has granted. The ticket is opaque to the application and anyone else outside of the network provider. The application attaches the ticket to its packets (in IPv6 HBH options) and sends them normally otherwise. At the first hop node in the network, the ticket is decoded by the network. Appropriate services are applied (e.g. set DSCP, set QoS, send into a tunnel or slice, etc.). The packet makes it's way to the destination with the ticket attached. The destination saves the ticket in it's context for communication. When the remote server replies, it attaches saved tickets as a "reflected tickets". When the return packet enters the client's network of the client, a node decodes the ticket and maps it to the right services for transit the provider networks back the UE. There are lot of details: like how to keep overhead low, how to make this secure ans stateless, how to limit scope of sensitive information, how to deal with paths that block HBH options. Please take a look at the FAST draft https://tools.ietf.org/html/draft-herbert-fast and white paper https://github.com/quantonium/papers/blob/master/FAST.pdf Tom > > Arashmid > > >> -----Original Message----- >> From: Tom Herbert [mailto:t...@quantonium.net] >> Sent: 07 September 2018 11:51 >> To: Arashmid Akhavain <arashmid.akhav...@huawei.com> >> Cc: Dino Farinacci <farina...@gmail.com>; ta-miyas...@kddi-research.jp; >> dmm <dmm@ietf.org> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain >> <arashmid.akhav...@huawei.com> wrote: >> > Correct, flow labels can change along the path. That's why I like the >> > slicing >> concept. >> > UEs can request services with different attributes, operators control how >> service request are mapped into slices. I should look into the air side of >> the >> business and see what happens there. >> >> Arashmid, >> >> Yes, slices are a good model. The key question is how does a user's packets >> get mapped to the right slice. Presumably, this is done at an ingress point >> into the network. There are two ingress points to be considered, one from >> UE into the network and one from Internet into network (return path). If the >> UE sets bits in the packet to get service in the forward path, we somehow >> need to have those bits available on packets in the return path to map >> incoming packets. In lieu or requiring the network to maintain a whole bunch >> of complex flow state, FAST arranges that the remote server reflects the bits >> in response packets. >> >> Tom >> >> > >> > >> > >> >> -----Original Message----- >> >> From: Tom Herbert [mailto:t...@quantonium.net] >> >> Sent: 07 September 2018 11:13 >> >> To: Arashmid Akhavain <arashmid.akhav...@huawei.com> >> >> Cc: Dino Farinacci <farina...@gmail.com>; >> >> ta-miyas...@kddi-research.jp; dmm <dmm@ietf.org> >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> >> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >> >> <arashmid.akhav...@huawei.com> wrote: >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Dino Farinacci [mailto:farina...@gmail.com] >> >> >> Sent: 06 September 2018 18:59 >> >> >> To: Arashmid Akhavain <arashmid.akhav...@huawei.com> >> >> >> Cc: Tom Herbert <t...@quantonium.net>; >> >> >> ta-miyas...@kddi-research.jp; dmm <dmm@ietf.org> >> >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis- >> 01 >> >> >> >> >> >> > Dino brought up a good point. Here is my two cents worth: >> >> >> >> >> >> Not sure which point. >> >> >> >> >> >> > As it was explained by Sridhar, each UE can have multiple >> >> >> > contexts. For >> >> >> example, today some operators provide Data and VoLTE service to >> >> >> their customers. These two services are represented by separate >> >> >> GTP tunnels in the core with each tunnel tied up to a particular QoS. >> >> >> > >> >> >> > IPv4 didn't fit the bill when GTP work was under way as it >> >> >> > couldn't uniquely identify multiple UE >> >> >> >> >> >> There is no reason why it shouldn’t. And IPv6, for this use-case >> >> >> doesn’t add anything new other than a 28 bit >> >> >> traffic-class/flow-label that can provide more bits for “new >> functionality”. >> >> > >> >> > >> >> > [Arashmid] And that's what I meant. Having a flow label is handy. >> >> > We can perhaps use it to identify different UE sessions. >> >> > >> >> Careful if you use the flow label to identify flows. It should be >> >> considered "soft identification" since it might not always be correct >> >> (it can be changed en route, isn't protected by any checksum, anyone >> >> can set it however they want, etc.). It's useful for things like ECMP >> >> that don't require 100% accuracy in identifying flow. The flow label >> >> was briefly considered for holding VNIs in network virtualization, but we >> talked them out of that. >> >> >> >> Tom >> >> >> >> >> >> >> >> > sessions/context/bearer. So, GTP and TEID did the job. But I >> >> >> > agree with >> >> >> Dino that IPv6 is much more versatile and is definitely worth >> >> >> looking at as an alternative. >> >> >> >> >> >> That is not what I said. I said “IP could have solved this problem”. >> >> >> And >> “IP” >> >> >> means either IPv4 or IPv6, or both at the same time. >> >> > >> >> > >> >> > [Arashmid] >> >> > How would we employ IPv4 to distinguish between different UE >> sessions. >> >> TOS? >> >> > Or you mean using encapsulation? >> >> > >> >> >> >> >> >> > A factor worth considering though is that the use of GTP and >> >> >> > TEID in mobile >> >> >> core allows operators to deal with QoS on their own terms. The >> >> >> tunnels with specific operator-controlled QoS are established by >> >> >> the control plane between eNB, SGW, and PGW. UEs or applications >> >> >> sitting in the UEs have no say in this. Well at least till the >> >> >> packet exits operator's >> >> network. >> >> >> >> >> >> The problem with one header, is that if you re-mark (known as PHB >> >> >> markign in the ole days) you lose the original value. >> >> >> Encapsulation is useful here because you can map the inner to >> >> >> outer and anywhere along the path you can PHB remark on the outer >> >> >> header. And then the destination can see the orignal source’s >> ToS/QoS/TC/flow-label whatever. >> >> > >> >> > >> >> > [Arashmid] Yes, I agree. The original value is lost with PHB. >> >> > Encapsulation certainly makes things easier and the inner to outer >> >> > mapping trick has been widely used in IP and MPLS(multiple labels >> >> > like service and transport) >> >> > >> >> >> >> >> >> > Using the information in UE's IP packet header can jeopardise >> >> >> > the above tight QoS control. I think going >> >> >> >> >> >> Not if you encapsulate. But note with SRv6, you can possibly >> >> >> retain the original flow-label if the SID can retain those bits >> >> >> before overwriting the destination address from the option’s value. >> >> > >> >> > [Arashmid] Agree. Encapsulation does the trick again. That's why >> >> > GTP has worked well and served the purpos in the mobile back-haul so >> far. >> >> > >> >> >> >> >> >> Dino >> >> >> >> >> >> > down this path, operators need proof that they will be still in >> >> >> > the driving >> >> >> seat and QoS cannot be dictated/tampered by the UE or any >> >> >> application running in it. >> >> >> > >> >> >> > Now, here is an interesting question for the operators. Would >> >> >> > any operator >> >> >> be interested in allowing QoS to be set by the UE or by >> >> >> applications running in the UE and charged for by the network? >> >> >> "Yes" could potentially imply impacts on the air interface, UE >> >> >> resource block allocation and can make scheduling on the RAN side >> much more complex. >> >> >> > >> >> >> > Arashmid >> >> >> > >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino >> >> >> >> Farinacci >> >> >> >> Sent: 06 September 2018 12:45 >> >> >> >> To: Tom Herbert <t...@quantonium.net> >> >> >> >> Cc: ta-miyas...@kddi-research.jp; dmm <dmm@ietf.org> >> >> >> >> Subject: Re: [DMM] Comments to >> >> >> >> draft-hmm-dmm-5g-uplane-analysis- >> >> 01 >> >> >> >> >> >> >> >>> Behcet, >> >> >> >>> >> >> >> >>> I was thinking if TEID is need then that can be encoded in a >> >> >> >>> locator easily enough. >> >> >> >>> >> >> >> >>> Tom >> >> >> >> >> >> >> >> Not if a locator is a PGW that is shared by many UEs. >> >> >> >> >> >> >> >> 3GPP wants per bearer awareness so they need a specific ID, >> >> >> >> that could have been the UE’s IP address. And with IPv6 it can >> >> >> >> be unique and not the issue that Sridhar brought up. >> >> >> >> >> >> >> >> If ILA was in use, just use the ILA-ID for this purpose. >> >> >> >> >> >> >> >> Dino >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> dmm mailing list >> >> >> >> dmm@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/dmm >> >> > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
