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.

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?

Section 1:

"Another aspects of user plane requirements couldn't be found." - I'm
not sure what this means

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?

"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.

"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.

"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).

"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.

"DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel
endpoint node based on the QFI." - This should be rectified with

"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.

"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.

"GTP-U supports active OAM as a path management message "Echo
Request/Response"" - Does GTP-U support in-situ OAM?

Header format "DSCP=0" in inner packet. Is this a requirement?

There should be some discussion about how ECN is handled. RFC6040
should probably be referenced.

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

"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? :-)

"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).

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.


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

dmm mailing list

Reply via email to