Hi Tom,
Firstly, I'd like to apologize for my late reply because of summer vacation.
We greatly appreciate your detailed review and feedback. We'll reflect
your feedback on the I-D at the next update. Please find my replies to
your comments in-line. (They are tagged with [SH])
By the way, please note that the purpose of this I-D is not denigrating
GTP-U but introducing what is GTP-U protocol to IETF folks. Therefore,
we consider that this document should describe just facts derived from
3GPP docs or general aspects.
Best regards,
Shunsuke
On 2018/08/12 3:49, Tom Herbert wrote:
Hi Shunsuke,
Thanks for the draft! It does a very good job of describing and
framing GTP-U using IETF terminology. This should help significantly
to bridge that gap of understanding between IETF and 3GPP.
Some comments:
General comment: Please look at "Encapsulation Considerations"
(https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02). There's a
lot of material there that might be relevant to encapsulation aspects
of GTP-U.
[SH] Thanks. We'll refer the document and update the content of GTP-U
section if there are points should be added.
General comment: There are a number of recommendations that could be
extracted and made to improve GTP (in section 3 in particular). Does
it make sense to these in their own document as a recommendation to
3GPP for a future update of GTP?
[SH] It's out of scope, however 3GPP folks may be able to use this I-D
to improve GTP.
Section 1:
"Another aspects of user plane requirements couldn't be found." - I'm
not sure what this means
[SH] It means the fact that the capture of TR 29 891 describes only "how
to carry 5G specific QoS information between UPF and access networks",
however, as you pointed out, it is not necessarily needed and we can
remove it at the next update.
Section 3:
"Allocation of UDP source port depends on sender tunnel endpoint node
and GTP-U supports dynamic allocation of UDP source port for load
balancing objective." - How is this done in practice. In most UDP
encapsulation protocols the UDP source is set to value from the hash
over a tuple of the encapsulated packet. This way, the outer packet
can ECMP router each encapsulated flow for load balancing. If this
were done in GTP-U this would probably mean that the source port is
not consistent for all packets sent on a tunnel. Would this be
consistent with 3GPP specifications?
[SH] As we described "however specific procedure, e.g., 5-tuple hashing,
is not described in the document" in the draft, GTP-U spec described in
TS29.281 just allows dynamic UDP src port allocation depend on network
deployment and network node implementation.
So it could also be consistent with the spec when the allocated src
ports are inconsistent on a tunnel.
"GTP-U does not support IPv6 flow label for load balancing in case of
IPv6 transport." - does the spec say anything about flow label, does
it need to be set to zero otherwise? This should be an easy fix since
setting flow label isn't a wire protocol change and setting flow label
has already commonly implemented in other encapsulations.
[SH] It is not also defined specific procedure in TS29.281.
"UDP zero checksum is not available in case of IPv6 transport." -
Setting a UDPv6 zero checksum is a little tricky. RFC6935 and RFC6936
need to be considered, but also the specifics and conditions of the
protocol an conditions of deployment. For instance, RFC8086 goes into
inordinate detail on requirements to set a zero UDPv6 checksum.
[SH] Thanks, it looks useful.
"GTP-U does not support to response ICMP PTB for Path MTU Discovery."
- I'm not sure what this means. Is this saying that if a GTP-U
endpoint receives an ICMP PTB error for a packet sent over tunnel, it
doesn't handle that; or is this saying that if a packet from a UE is
dropped at a GTP tunnel ingress point because of MTU exceeded then no
ICMP PTB is sent? If it's the first case, then that's not much a
problem. I doubt PMTU discovery has been implemented for many tunnels.
Usually one of the suggestions in RFC4459 is used (that RFC should be
referenced in the draft). If it's the second case, then that is more
of a bug in the protocol that should be fixed (this is IP layer
requirements, should not be specific to GTP-U).
[SH] Both of what you pointed out are possibly to occur. As Sridhar,
3GPP folk, described in the LS-OUT, 3GPP has assumption that MTU between
RAN and the P-GW or UPF is discovered by offline means and the operator
takes into account the MTU that is transferrable on the radio interface
and based on this the operator configures the right MTU to be used.
Therefore they don't consider there are any MTU issues. We'll add this
supplemental description about why it would be a problem at the next
update.
"Following list summarizes every extension header which is used for
user plane protocol." - Used or defined? It would be good to know
which, if any extension headers are commonly used in the data path.
This will also be input to the issued raised later on about the
efficiency of extension header processing.
[SH] It means defined extension headers. Of course, some extension
headers are used in the real networks.
"DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel
endpoint node based on the QFI." - This should be rectified with
RFC2983.
[SH] What this observation means is that UPF remark DSCP value of outer
IP header based on QFI of GTP extension header, and how to handle GTP-U
packets with DSCP is out of scope.
"In general, multiple GTP-U extension headers are able to contained in
one GTP-U packet and the order of those extension headers is not
specified by [TS.29.281-3GPP]." - That is the combinatoric nature of
TLVs. There has been much discussion on that. A potentially related
question would be does GTP-U limit the number or size of extension
headers (unlimited TLVs in a packet could be used as a potential
denial of service attack.
[SH] Yes, you're correct. Meanwhile, the problem that we indicated here
is ambiguity of 3GPP spec and effect on hardware performance caused by
the ambiguity.
Maybe, each vendor implementation would have its own specification about
limit on the number, order, and capable types of extension headers.
Nevertheless, do you think we should add the concern related to limit
the number of extension headers?
"GTP-U does not support to indicate next protocol type." - A bit
unfortunate, IMO an encapsulation should also have a type field.
Conceptually, there is a way around this by defining the the first
nibble after GTP-U headers to be a type field (similar to GUEv1). 0x4
and 0x6 are IPv4 and IPv6, which is convenient since this coincides
with the version number of an overlaid encapsulated IP packet. Other
values could be used for different types.
[SH] It's also good point. We'll add the aspect.
"GTP-U supports active OAM as a path management message "Echo
Request/Response"" - Does GTP-U support in-situ OAM?
[SH] No, it doesn't. GTP-U supports only keep-alive by using Echo
Request/Response sent regular basis.
Header format "DSCP=0" in inner packet. Is this a requirement?
[SH] There are no definitions on inner IP packet. The figure describes
"DSCP=0" as just an example.
There should be some discussion about how ECN is handled. RFC6040
should probably be referenced.
[SH] Thanks. We'll consider how to mention ECN handling at the next update.
Section 4:
"Then, the content information of the PDU may be mapped into UDP port
number" - I don't follow this. Does this mean that different
destination port numbers are used to determine the protocol of the
T-PDU?
[SH] Sorry, if this description is misleading. The section 9.2 of
TS29.561 defines that IPv6 address and UDP port number for unstructured
PDU type data is pre-configured at UPF, and the UPF associates GTP-U
tunnels with N6 PtP tunnel based on the UDP port destination. Although
we couldn't find concrete definitions about unstructured PDU type data,
some variations of UDP port numbers might be needed if there are some
types in unstructured PDU data.
"For this, the expected evaluation points from this aspect should be
whether there is substitutional means to cover other PDU session
types. And how much it makes simple the system than deploying
original PDU session types." - Is this another way of saying the
encapsulation protocols should have type field? :-)
[SH] Type field seems good point to simplify the system. We'll add the
aspect as an example.
"However it increases header size from 20bytes to 40bytes compare to
IPv4." - That's also an overhead problem. In a bandwidth constrained
IoT network where average packet sizes might be as little at 100
bytes, the overhead of two IPv6 headers, GTP-U header and extensions,
and an eight byte UDP header becomes significant to the extent that
overhead packet becomes majority portion of bytes. Techniques to
reduce the overhead could be warranted (ILA is one optimization that
does that).
[SH] As you described, overhead problem would be a point to evaluate
candidate protocols. Although there seems to be no clear requirements
for overhead of encapsulation in 3GPP 5G, we can add such aspect if it
is general problem and useful for comparing candidate protocols.
Section 5 is good, but it would be nice to highlight whether or not
GTP-U can satisfy the evaluation aspects. Most of the problems of
GTP-U listed in section 3 are relatively minor and can be addressed
without significant protocol change (e.g. turning on flow label should
be trivial). The biggest feature touted by the candidate protocols
seems to be anchor-less mobility (might be a topic worth mentioning in
the draft). AFAICT, GTP-U is sufficiently generic and extensible so
that it could be used a the user plane of anchor-less mobility without
much change. Control plane would need major changes, but that is
probably similar to what needed in the control plane for other user
plane protocols to provide anchorless mobility.
[SH] Such highlight is a good idea, but 3GPP folks may not hope that
IETF evaluates GTP-U that is 3GPP protocol. Please let us consider
whether it can be added in this I-D. Also, as I described at the
beginning of this email, the purpose of this I-D is clarifying and
introducing GTP-U protocol and we assume that we don't need to provide
shorts of GTP-U intentionally.
Tom
On Fri, Aug 10, 2018 at 2:24 AM, Shunsuke Homma
<homma.shuns...@lab.ntt.co.jp> wrote:
Hi DMM folks,
We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis and
uploaded the new version. We need more reviews from both IETF and 3GPP for
further improvement. We will appreciate if you can give comments or feedback
to this I-D.
Best regards,
Shunsuke
-------- Forwarded Message --------
Subject: New Version Notification for
draft-hmm-dmm-5g-uplane-analysis-01.txt
Date: Fri, 10 Aug 2018 01:44:20 -0700
From: internet-dra...@ietf.org
To: daniel.vo...@bell.ca <daniel.vo...@bell.ca>, Daniel Voyer
<daniel.vo...@bell.ca>, Takuya Miyasaka <ta-miyas...@kddi-research.jp>,
Satoru Matsushima <satoru.matsush...@g.softbank.co.jp>, Shunsuke Homma
<homma.shuns...@lab.ntt.co.jp>
A new version of I-D, draft-hmm-dmm-5g-uplane-analysis-01.txt
has been successfully submitted by Shunsuke Homma and posted to the
IETF repository.
Name: draft-hmm-dmm-5g-uplane-analysis
Revision: 01
Title: User Plane Protocol and Architectural Analysis on 3GPP 5G
System
Document date: 2018-08-10
Group: Individual Submission
Pages: 30
URL:
https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.txt
Status: https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/
Htmlized: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hmm-dmm-5g-uplane-analysis
Diff: https://www.ietf.org/rfcdiff?url2=draft-hmm-dmm-5g-uplane-analysis-01
Abstract:
This document analyzes the mobile user plane protocol and the
architecture specified in 3GPP 5G documents. The analysis work is to
clarify those specifications, extract protocol and architectural
requirements and derive evaluation aspects for user plane protocols
on IETF side. This work is corresponding to the User Plane Protocol
Study work on 3GPP side.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--
----------------------------------
Shunsuke Homma
<homma.shuns...@lab.ntt.co.jp>
TEL: +81 422 59 3486
FAX: +81 422 60 7460
NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
