Skip to main content

Minutes IETF109: intarea
minutes-109-intarea-02

Meeting Minutes Internet Area Working Group (intarea) WG
Date and time 2020-11-19 07:30
Title Minutes IETF109: intarea
State Active
Other versions plain text
Last updated 2020-12-08

minutes-109-intarea-02
IntArea WG Agenda
IETF 109 - Virtual
Thursday, November 19, 2020 (+07)

14:30-15:30 Thursday Session II

Chairs:
Juan Carlos Zuniga (SIGFOX)
Wassim Haddad (Ericsson)

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

Juan Carlos going through the usual BCP and IPR introduction
Agenda bashing
David Schinazi (DS): Questions about items 3,4,5: are these transport
documents? why in INTAREA? (discussed with chairs, they approved) not touching
transport protocol, just application protocol Éric Vyncke/AD: if its a tunnel,
its INTAREA not adopted, just first time presentation continue discussion in
that slot Doc status updates: RFC 8900 published on frag considered fragile

2. SOCKS Protocol Version 6, Vladimir Olteanu
10 minutes
draft-olteanu-intarea-socks-6-11

no discussion Vladimir not showing up online, skipped.
Chair: Call for Adoption still open, has been presented a few times,
implementations exist. Will fwd to SAAG, SECDISPATCH, MASQUE lists. Please
discuss adoption on ML.

3. Tunneling Internet protocols inside QUIC, Maxime Piraux
4. Session mode for multiple QUIC Tunnels, Maxime Piraux
5. Tunneling TCP inside QUIC, Maxime Piraux

draft-piraux-intarea-quic-tunnel-tcp-00
draft-piraux-intarea-quic-tunnel-00
draft-piraux-intarea-quic-tunnel-session-00

(all the drafts were rolled up in one presentation)

Maxime: Tunneling internet protocols inside quic

Split in 3 documents (this and next 2 items)

reading slides, proposing QUIC as an alternative to IPSEC, TLS and DTLS

encapsulates packets in datagram frames

tunnel session for multihomed client

separate QUIC connections preferred over MP-QUIC
same session, concentrator does reordering
stream mode saves overhead, TCP to QUIC mapping

Discussion

David Schinazi: already done with MASQUE?
Maxime: MASQUE define atop HTTP/3, here no need
Also multihome
David: once QUIC supports multipath, we'll get it for
free in MASQUE. I'd suggest bringing the energy and
requirements to the MASQUE WG.
Tommy Pauly: do not duplicate work
already possible to do thin and lightweight
Éric: not the usual kind of tunnel, looks a lot like MASQUE
meeting with INTAREA and MASQUE chairs and A-Ds early December
Seems usable as input for the MASQUE WG
Christian Huitema: harder to do the MP than presented, think server pool.
Eric Kinnear: MASQUE is effectively looking at this, especially Multipath.
Better not be in front of the MP discussion at QUIC. Nothingin MASQUE is
anti-MP. Vidhi Goel: Q on scheduling over MP. Is it discussed? Maxime: no
position taken on this. Jana Iyengar: were QUIC | MASQUE chairs or TSV A-Ds
consulted? JC: not done, we decided to hear it because of the tunnel argument;
taking this as feedback that we could/should have

6. SCHC over PPP, Pascal Thubert
10 minutes
draft-thubert-intarea-schc-over-ppp-00

Static Context Header Compression mode, for PPP. requires some new
flagging/signalling for PPP, to handle the new encoding. Because PPP is on lots
of substrates (3GPP) this makes for easy deployment over other things. Seeking
adoption Discussion

Question on Meetecho: "How many people have read the draft?"
Raise of Hands: 4-Yes, 19-No, 118-Present

Chair calls for more people to read the draft.

7. Scenarios for Flexible Address Structure, Yihao Jia
5 minutes
draft-jia-scenarios-flexible-address-structure-00

reading slides content

new flexible format for new routing capabilities
for use in edge domains
Discussion

Pascal: "some inexactitude wrt 6LoWPAN, compressed packets can be forwarded in
compressed form, see RFC 8138 for route over, and in fragmented form with RFC
8930 and RFC 8931. Pascal: 6LoWPAN is not a flexible structure, its a
compression mechanism so it may not compare anyway" See this as “parallel”
structure, e.g. for IoT Ron: Have use-cases require additional info, proposed
encoding in address, variable-length addressing… no longer IPv6 when you do
this. Think about encoding somewhere else than dest address e.g. EH. Maybe this
is IPv10 Not exactly IPv6, used address definitions, hope the structure could
be variant from 128bytes, could contain more semantics so yes, different. But,
could be “compatible” Ted: Thanks, are the scenarios reasonable? No. for 3
reasons: programmatic, architectural and policy. Works only when going through
a gateway, terrible idea if we want to keep the internet whole. Ted: Also
Privacy: encoding a user ID iin the address defeats privacy. Ted:
Recommendation: pick one use case and figure the best tool for that.

JCZ: Running out of time. Next drafts will have to be discussed on the list

(Meeting adjourned)

8. Flexible IP: An Adaptable IP Address Structure, Yihao Jia
5 minutes
draft-jia-flex-ip-address-structure-00
* no time to present

9. Per-Application Networking Considerations, Lorenzo Colitti
(time permitting)
draft-per-app-networking-considerations
* no time to present