Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
 wrote:
> Thank you Tom for your suggestion.
>
> Do you think that GUE has some advantages against GTP-U?

I believe so. GUE is designed to be a general purposed multi use case
encapsulation. The defined GUE extensions deal with problems and
provide features of encapsulation (header security, fragmentation,
payload security, checksum handling etc.). This is done without
resorting to expensive TLV processing. GUE also allows "private data"
that could be used for use case specific info-- so TLVs or GTP
extensions could be encoded so in that sense it's a superset of GTP
functionality. As I mentioned, GUE has a mode for encapsulating IP in
UDP with minimal overhead (direct IP over UDP).

> When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
> GTP-U?
>
I think so. Perhaps the biggest advantage is the GUE can be used
accross different use cases and technologies. It's generic protocol so
it could be used for multiple use cases in a mobile network. For
instance, a UE might talk to a a low latency service application via
GUE. To the server this looks much more like simple virtualization or
encapsulation and GUE includes potential optimizations. Similarly, GUE
also could be use to connect across different access technologies that
might not be 3GPP (like roaming between WIFI and a mobile network).
Conceptually, other IETF defined encapsulations could also be used for
this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
to be multi use case, low overhead, but still extensible.

We intend to use ILA in a similar multi-use case fashion, however when
encapsulation is required (like SR TE is needed, or we need an
encrypted tunnel) then I believe GUE is a good alternative for that
case to provide necessary functionality and extensibility.

Tom

>> 2018/03/27 9:16、Tom Herbert のメール:
>>
>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>>  wrote:
>>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>>>
>>> We are also waiting for Lyle to share his notes. Please review and
>>> comment, if you see any mistakes.
>>>
>>
>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>> Why not using UDP encapsulation?"
>>
>> There is some rationale for UDP encapsulation here to maximize
>> compatibility with the network and potentially intermediate nodes like
>> firewalls. For example, in the performance numbers that Kalyani
>> posted, the TPS for SR over IPIP routing was lower than other
>> encapsulations. The reason for this is that the particular NIC (ixgbe)
>> is not parsing over IPIP or using flow label to get a good hash for
>> RSS. This is symptomatic of network devices that don't provide as good
>> support for protocols outside of TCP and UDP. There are likely routers
>> that would not be able to provide flow specific ECMP for similar
>> reasons. There was a comment in dmm meeting that ECMP for IPIP was
>> expected to by solved by using flow label in the hash. This is a great
>> idea, but unfortunately there is significant resistance to using flow
>> label for this purpose since it is not guaranteed to be persistent for
>> a flow and that can cause problems for stateful devices like
>> firewalls.
>>
>> UDP encapsulation is the typical answer to network protocol
>> compatibility. Several UDP encapsulation techniques have been defined
>> as well as some foo over UDP to run existing encapsulations over UDP
>> (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
>> overview of considerations for UDP encap protocols.
>>
>> If a UDP encapsulation is considered for use with SR, I would suggest
>> GUE is an option. GUE has some unique features:
>>
>> - It's extensible (both common extensions are defined and allows
>> custom extensions per use case)
>> - It's generic (can encapsulate any IP protocol)
>> - It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
>> encapsulation overhead)
>> - It allows encapsulation of extension headers
>>
>> The last point may be of particular interest to SR. SR over IPIP might
>> be more precarious compared to other encapsulations since it
>> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
>> be used to normalize SR packets to look like UDP to the network. This
>> might look something like:
>>
>> IP|UDP|GUE|Routing_hdr|IP|payload
>>
>> The UDP and GUE header are effectively treated as routing shim at each
>> segment hop so SR is processed as without regard to the encapsulation.
>> To intermediate nodes these packets looks like any other UDP packet so
>> there's no compatibility issue.
>>
>> Tom
>>
>> ___
>> 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

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Satoru Matsushima]

Thank you Tom for your suggestion.

Do you think that GUE has some advantages against GTP-U?
When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
GTP-U?

Best regards,
--satoru



> 2018/03/27 9:16、Tom Herbert のメール:
> 
> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>  wrote:
>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>> 
>> We are also waiting for Lyle to share his notes. Please review and
>> comment, if you see any mistakes.
>> 
> 
> With regards to SR encapsulation: "this is using IP-in-IP as default.
> Why not using UDP encapsulation?"
> 
> There is some rationale for UDP encapsulation here to maximize
> compatibility with the network and potentially intermediate nodes like
> firewalls. For example, in the performance numbers that Kalyani
> posted, the TPS for SR over IPIP routing was lower than other
> encapsulations. The reason for this is that the particular NIC (ixgbe)
> is not parsing over IPIP or using flow label to get a good hash for
> RSS. This is symptomatic of network devices that don't provide as good
> support for protocols outside of TCP and UDP. There are likely routers
> that would not be able to provide flow specific ECMP for similar
> reasons. There was a comment in dmm meeting that ECMP for IPIP was
> expected to by solved by using flow label in the hash. This is a great
> idea, but unfortunately there is significant resistance to using flow
> label for this purpose since it is not guaranteed to be persistent for
> a flow and that can cause problems for stateful devices like
> firewalls.
> 
> UDP encapsulation is the typical answer to network protocol
> compatibility. Several UDP encapsulation techniques have been defined
> as well as some foo over UDP to run existing encapsulations over UDP
> (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
> overview of considerations for UDP encap protocols.
> 
> If a UDP encapsulation is considered for use with SR, I would suggest
> GUE is an option. GUE has some unique features:
> 
> - It's extensible (both common extensions are defined and allows
> custom extensions per use case)
> - It's generic (can encapsulate any IP protocol)
> - It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
> encapsulation overhead)
> - It allows encapsulation of extension headers
> 
> The last point may be of particular interest to SR. SR over IPIP might
> be more precarious compared to other encapsulations since it
> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
> be used to normalize SR packets to look like UDP to the network. This
> might look something like:
> 
> IP|UDP|GUE|Routing_hdr|IP|payload
> 
> The UDP and GUE header are effectively treated as routing shim at each
> segment hop so SR is processed as without regard to the encapsulation.
> To intermediate nodes these packets looks like any other UDP packet so
> there's no compatibility issue.
> 
> Tom
> 
> ___
> 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

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
 wrote:
> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>
> We are also waiting for Lyle to share his notes. Please review and
> comment, if you see any mistakes.
>

With regards to SR encapsulation: "this is using IP-in-IP as default.
Why not using UDP encapsulation?"

There is some rationale for UDP encapsulation here to maximize
compatibility with the network and potentially intermediate nodes like
firewalls. For example, in the performance numbers that Kalyani
posted, the TPS for SR over IPIP routing was lower than other
encapsulations. The reason for this is that the particular NIC (ixgbe)
is not parsing over IPIP or using flow label to get a good hash for
RSS. This is symptomatic of network devices that don't provide as good
support for protocols outside of TCP and UDP. There are likely routers
that would not be able to provide flow specific ECMP for similar
reasons. There was a comment in dmm meeting that ECMP for IPIP was
expected to by solved by using flow label in the hash. This is a great
idea, but unfortunately there is significant resistance to using flow
label for this purpose since it is not guaranteed to be persistent for
a flow and that can cause problems for stateful devices like
firewalls.

UDP encapsulation is the typical answer to network protocol
compatibility. Several UDP encapsulation techniques have been defined
as well as some foo over UDP to run existing encapsulations over UDP
(e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
overview of considerations for UDP encap protocols.

If a UDP encapsulation is considered for use with SR, I would suggest
GUE is an option. GUE has some unique features:

- It's extensible (both common extensions are defined and allows
custom extensions per use case)
- It's generic (can encapsulate any IP protocol)
- It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
encapsulation overhead)
- It allows encapsulation of extension headers

The last point may be of particular interest to SR. SR over IPIP might
be more precarious compared to other encapsulations since it
introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
be used to normalize SR packets to look like UDP to the network. This
might look something like:

IP|UDP|GUE|Routing_hdr|IP|payload

The UDP and GUE header are effectively treated as routing shim at each
segment hop so SR is processed as without regard to the encapsulation.
To intermediate nodes these packets looks like any other UDP packet so
there's no compatibility issue.

Tom

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm