IntArea WG Agenda

IETF 118 - Hybrid meeting, Prague (Czech) + Online
Thursday, November 9, 2023

15:00-16:30 Thursday Afternoon Session III (CET, UTC+1)

Chairs

Juan Carlos Zuniga (Cisco)
Wassim Haddad (Ericsson)

Note Taker

Stuart Cheshire (Apple)

1. Agenda Bashing, WG & Document Status Updates (Chairs)

5 mins

IANA Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters (draft-ietf-intarea-rfc7042bis-11) is now in the RFC
Editor Queue and will be published soon.

Protocol numbers for SCHC (Static Context Header Compression)
(draft-ietf-intarea-schc-protocol-numbers-01) originally came from the
LPWAN working group, and then moved to IntArea.

Éric Vyncke (Cisco): This document will now be moved to the new SCHC
working group (as its charter allows it), with WG Last Call handled
jointly between SCHC and IntArea.

2. Communicating Proxy Configurations in Provisioning Domains - Tommy Pauly

draft-pauly-intarea-proxy-config-pvd-01
10 mins

Tommy Pauly (Apple) presented a summary of changes in draft-01. This
provides a standard alternative to WPAD and PAC. Is this a document that
IntArea would like to adopt?

Erik Kline (Aalyria): I support adopting this. We should discuss
duplicate or overlapping domains, where multiple proxies claim to be the
best way to reach the same resources.

Tommy Pauly (Apple): Yes, this especially applies for network-discovered
proxies.

Ted Hardie (Cisco): Some people might provide UDP proxies, but not want
certain traffic (e.g., MoQ) running through those proxies, because the
proxy can’t provide the quality of service that the traffic requires.

Tommy Pauly (Apple): We may need a way to describe the properties of
proxies.

Ted Hardie (Cisco): Maybe ALPN could be useful for this.

Josh Cohen (no affiliation): WPAD was done 25 years ago. Happy to see
evolution on this. Happy to see that people are cooperating on this
work. Happy to help with network discovery aspects.

Mirja Kühlewind (Ericsson): Glad to see the list of safeguards regarding
network discovery.

Suresh Krishnan (Cisco): Not comfortable with the list of heuristics
about which protocol to use.

Éric Vyncke (Cisco): I think this is a good fit for IntArea. When it is
ready for Working Group Last Call, that should be sent to appropriate
other working groups too.

3. Trusted Domain SRv6 - Andrew Alston

draft-raviolli-intarea-trusted-domain-srv6-01
15 mins

Andrew Alston (Liquid Labs) presented overview of Trusted Domain SRv6
(TD-SRv6)

Jan Zorz (6connect): SRv6 is not IPv6. It should have its own EtherType.

Shin Miyakawa (NTT Communications): I am supporting this. Is this
optional, if we define the new EtherType?

Andrew Alston (Liquid Labs): People have deployed this. I would prefer
that people always new the new EtherType, but operators can run it both
ways. As an operator, I would not trust MPLS coming in from untrusted
sources. Other operators may have a different view.

Tianji Jiang (China Mobile): I asked questions in San Francisco, but
draft-02 does not address these, so I will ask similar questions again.
What if tens of thousands of routers have to be upgraded one by one? We
have so many tools already, like access control lists. This is
unnecessary.

Andrew Alston (Liquid Labs): This is optional. You don’t have to deploy
this. You are not forced to do this. If you have SRv6 already running on
tens of thousands of routers that will continue to work. Things like
MPLS are not enabled automatically by default on all interfaces.

Tianji Jiang (China Mobile): What will stop other people asking for a
new EtherType?

Andrew Alston (Liquid Labs): Applying for a new codepoint for a new use
case is perfectly normal. The purpose of this is to give operators an
alternative choice if they choose to use it.

Éric Vyncke (Cisco): I like the approach that this is optional. The call
for adoption needs to be delayed, until Suresh Krishnan's 6MAN draft is
approved and the SRv6 security considerations draft in SPRING is mature
enough to ensure that this EtherType draft addresses correctly the
security gaps of SRv6.

Andrew Alston (Liquid Labs): We see Suresh’s draft as being
complementary. The two documents (this draft and the SRv6 security
draft) are orthogonal.

Éric Vyncke (Cisco): I agree, this draft and the SRv6-security one are
not overlapping, but they are sequential.

Andrew Alston (Liquid Labs): This draft fixes an important problem that
we want to solve quickly.

Éric Vyncke (Cisco): Delaying WG adoption does not need to prevent you
from continuing to work on this and make progress.

4. Reverse Traceroute, Valentin Heinrich

Augsburg Technical University of Applied Sciences (Technische Hochschule
Augsburg / THA)
draft-heiwin-intarea-reverse-traceroute-02
15 mins

For asymmetric paths, delays on hops on the reverse path can
incorrrectly appear to be delays on certain outbound hops.

RFC 1393 (Traceroute Using an IP Option) was published in January 1993,
obsoleted in 2012.

Tobias Fiebig (Max-Planck-Institut für Informatik): Which
implementations did you test?

Valentin Heinrich (THA): I will get you the complete list.

Tobias Fiebig (Max-Planck-Institut für Informatik): This may not be a
good candidate for using ICMP because it requires the other end to
maintain state.

Erik Kline (Aalyria): You should you look at the work in IPPM. They are
working on one-way and two-way measurement protocols.

Éric Vyncke (Cisco): You should present your draft in IPPM. Inducing
endpoints to store state may be a problem — and in this context
endpoints include any device on the Internet, including routers.

Valentin Heinrich: Endpoints can limit how much they store.

5. Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions, Marc Blanchet

draft-many-deepspace-ip-assessment-00
15 mins

Bundle Protocol was created based on an assumption that it is
fundamentally impossible to modify IP to make it suitable for high-delay
networks (e.g., 40-minutes round-trip time). Is that true? A space
network might not interconnect directly with the terrestrial Internet,
but does that mean it can’t be built using a version of IP modified for
that environment?

Jorge Amodio (ISOC IPNSIG): It is better to make a completely new
protocol instead of adapting existing protocols.

Stuart Cheshire (Apple): I support the work you are doing here, but when
you say that “IP has no notion of time”, that’s not completely true. The
IP TTL (Time To Live) count was intended to bound the maximum number of
seconds a packet can remain in the network. TCP makes use of this
guarantee to establish the TCP MSL (maximum segment lifetime) to
determine how long an implementation has to guard against an old packet
appearing, for purposes of determining when it is safe to re-use
sequence number values, and how long a system must keep connection
information in TIME_WAIT state, and so forth. Transport protocols and
applications will need to have knowledge of the timliness guarantees (if
any) made by the underlying network.

Tim Chown (Joint Information Systems Committee (Jisc)): Do we need to
update RFC 1149 for space? (This is a joke.)

Alexander Pelov (IMT Atlantique): IP runs over LPWANs, which can be very
slow. Even though it may be slow, you can still run ssh over LoRaWAN.

6. Identification Extension for the Internet Protocol - Fred Templin

draft-templin-intarea-ipid-ext-22
10 mins

Fred Templin presented graphs showing that HDTN’s LTP/UDP shows
significant performance increases when segment sizes that exceed the
path MTU and invoke IP fragmentation are used in comparison with using
segment sizes no larger than the path MTU. For a 1500 byte path MTU for
example, a 16000 byte segment using fragmentation gave a factor 2
performance increase over a 1400 byte segment size not using
fragmentation. However, the system call overhead of sending UDP packets
individually, with a system call per packet, still limited the maximum
sending rate even of the unrestrained UDP flood. Sending oversized UDP
packets larger than the IP MTU, and letting the kernel break them into
IP fragments, reduced the software overhead by generating multiple IP
packets per system call. Fewer and larger segments perform better than
more and smaller segments (confirmed by ION DTN LTP large segment
performance vs. GSO/GRO). Increasing path MTU and using transport
protocol segments close to MTU size significantly increases performance,
but most Internet paths still 1500 or smaller. Using transport protocol
segments that exceed common Internet sized path MTUs significantly
increases performance when IP fragmentation invoked (Possibly the
software overhead could also have been reduced by using newer APIs that
allow batch sending of multiple UDP packets with single system call.)
However, as pointed out in RFC 8900 (IP Fragmentation Considered
Fragile), on real networks intentionally fragmenting IP packets actually
harms performance and reliability. Therefore a new mechanism is
proposed, called Deep Packet Fragmentation, to extend the use of
fragmentation in the Internet by using a larger packet identifier field
to allow more liberal use of IP fragmentation in the Internet. (Possibly
using a more efficient UDP API on the sender could enable the same
increase in sending rate without having to change the way the rest of
the Internet works.)

Lorenzo Colitti (Google): Sending fragmented packets on a real nework
waives the sender’s right to expect good performance or reliability. It
just doesn’t work. It might appear to work in a constrained network, but
test results from two machines connected back-to-back are not
representative of performance on a real network like the Internet. Any
nontrivial amount of packet loss results in the reassembly buffer
becoming full.

Edgar Ramos (Ericsson): The graphs showed a single flow of data. What
effect would that flow of data have on other traffic sharing the
network?

Meeting Ended