maprg at IETF 120

Overview and Status - Mirja/Dave (5 min)

The introduction slides include some highlights of TMA'24 (June 23, 24
2024)
for IETF partipants, e.g., focusing on DNS, BGP, and L4S.

Heads-Up/ANRW talk: HTTP/3’s Extensible Prioritization Scheme in the Wild - Joris Herbots (5 mins) (in-person)

No questions/comments. See related paper (link in slides).

Peaking Beyond the Best Route: An Extensive Dataset for Looking Glasses - Pascal Hennen (15 mins) (remote)

• Wes Hardaker: How large is the collected data volume? How many
  bytes?
  Pascal Hennen: Roughly 2GB (for the most recent one), compressed
  quite a lot.

Testing Protocols in Simulated Network Conditions - Tommy Pauly (10 mins) (in-person)

• Matt Mathis: How much work did you do to compare the simulations to
  real measurements?
• Tommy Pauly: used measurements to build profiles. We don't need to
  have every single network represented, we just need to explore the
  space so that we don't have a blindspot.

• Matt Mathis: (concurs)

• Lorenzo Colitti: With proxies and VPNs, when we're using UDP,
  session timeouts are short in some networks, so if all traffic is on
  these proxies, we can never get rid of TCP. It would be nice to know
  if the simulated environments can simulate that , and if we know how
  low those timeouts are (based on real data). Keeping TCP around
  forever means we can't use proxies foreverything; some things need
  long-lived TCP connections outside the proxy.

• Tommy Pauly: Good point.

• Stuart Cheshire: (comment about background motivation for such
  simulations) Back more than 10 years, Apple developed AppleTV using
  only wired ethernet in the office, and near time to ship, it was
  discovered it didn't work in home environments.

• Chris Seal: Characteristics between 3G vs. 4G/5G are dramatically
  different, can we break out "cell" to individual technologies.

• Tommy Pauly: sure.

• Kouhei Ueno: How is the packet path simulated here?

• Tommy Pauly: I don't remember the details for the dummynet
  implementation, but it's a great thing to discuss.

Watching Stars in Pixels: The Interplay of Traffic Shaping and YouTube Streaming QoE over GEO Satellite Networks - Jiamo Liu (15 mins) (remote)

• Lorenzo Colliti: similar small network that freezes. Closes and
  re-establishes TCP connections, so each ends back up in cold start.
  YouTube probably reuses TCP connections, but even if you close them
  you get worse. I don't know how to solve them, but blocking QUIC
  just gets complaints about it. Presenting it is a first step to
  getting people to understand that the quality of experience is not
  great.

• Gorry Fairhurst: have you looked at talk about QUIC over high-BDP
  paths?

• Jae Chung : In a long RTT high-BDP network, we see slow start being
  a huge problem. Trying to optimize slow start performance, that's
  the research direction we're heading in. Have a talk in CCWG on
  this, do come attend if interested. See also SCONEPRO BOF.

• Ben Schwartz: Solution to this was increasing the BDP by removing
  the bandwidth limiter. It was the traffic shaper that made it behave
  badly. Knowing how the traffic shaper was working might help. If
  simulating a low throughput network, policers made things extra
  weird. Pay close attention to the behavior of the shaper/policer.

• Matt Mathis: There's complexity around anticipating content, an
  experiment that might be useful would be to run this on a synthetic
  network where you can control the parameters, see if there are
  delays where behavior changes, as there may be timers in the
  protocols that should be adaptive, and give that feedback to
  implementors.

A First Look At NAT64 Deployment In-The-Wild - Amanda Hsuan (15 mins) (remote)

• Jen Linkova: Deploying v6 only network in a large enterprise. DNS64
  is not strictly required for clients using NAT64. Clients using
  CLAT, you can give them the prefix via other means, should be
  decoupled. You measured public resolvers, you may need a different
  resolver for DNS64. Broken configuration if public resolver gives
  DNS64 answer in general because it might cause delays. How do you
  know if clients are using NAT64?

• Amanda: With atlas probes we tried to request a AAAA record for
  domains and look at responses, means client is using DNS64 but
  doesn't guarantee that it's using NAT64.

• Stuart Cheshire: When studying this be very careful to separate
  NAT64 from DNS64. NAT64 is broadly a good idea while DNS64 is
  broadly not. When this was first created, you put in a NAT64 gw and
  then put in a DNS64 hack that make it work. Compared to all the
  services, there aren't that many different clients. It's better to
  do this locally in the client (see RFC 8880). DNS64 is a problem for
  DNSSEC. If you're [...]. Whole model assumes DNS64 and NAT64 are
  managed by the same entity. Clients can get the NAT64 prefix a range
  of ways. Thread only supports IPv6, so only Thread network is IPv67.
  Thread networks are required to do NAT64 but not DNS64 and have to
  do their own synthesis. Be careful to separate DNS64 and NAT64 as
  they are different problems with different deployments.

• Ben Schwartz: Hundreds of millions of people whose internet
  connectivity depends entirely on NAT64, interesting they don't show
  up here. Conclusion is the RIPE probes are missing some important
  huge chunks of the space and are going to give us misleading
  results. Interesting to think about how we could get to that
  information. Might be possible to come up with packets that would
  work end-to-end but fail NAT64.

• Lorenzo Colitti: Reason you won't find lots of DNS64 in public
  resolvers is that the config of DNS64 is tied tightly to the NAT64,
  as resolver and NAT need to agree on prefix to use. Also don't have
  lots of RIPE Atlas probes in mobile network environmnets. You
  wouldn't expect to find DNS64 in public networks.

• Robert Kisteleki: (I work for RIPE and am somewhat involved in
  ATLAS) I would love to have ATLAS probes in every network, but
  that's not going to happen. We're not really present in mobile
  networks, where you might observe this behavior more often. I would
  caution extrapolating results, as the system is not designed to do
  that.

Preparing to Detect IPv6 Attacks on Your IoT Devices - Phil Roberts (15 mins) (remote)

(Presenter lost network connectivity part way through)
(Leslie Daigle picking up presenting)

• Wes Hardaker: Thank you, it's not easy to get something like this
  out there. Would be nice to see more.

Understanding anomalies using a baseline dataset comparison - Wes Hardaker (10 mins) (in-person)

• Laurent Ciavaglia: Thanks, looks very nice. Do you have to tag where
  the problem is? Do you put any kind of rules or anything? Just
  statistics?
• Wes: Correct, no rules, just TCP filters if you want.

Field Experiments on Post-Quantum DNSSEC - Peter Thomassen/Jason Goertzen (15 mins) (in-person)

• Ben Schwartz: Really cool to see a running demo of PQ in DNSSEC. For
  public resolver, what alg IDs were you using since they don't exist.
• Answer: used 17-22 since wanted to look normal
• Ben: correct me if I'm wrong since only thing that matters is size,
  since opaque bytes for things in the chain
• Answer: size is why seeing failures
• Ben: As a DNS developer, curve of failure rate vs signature size is
  the really interesting thing, and the shape of that curve would be
  really interesting to see.
• Answer: with (falcon?) were staying under the MTU, but going over
  that greatly increased the error rate.