Monday, March 18th, 2024, from 15:30 (UTC+10) to 17:00 (UTC+10) (90
mins)
Time: 15 minutes 15/90
RFC 6937bis updates
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-06
Speaker: Neal Cardwell (remote)
Time: 20 mins 35/90
Yoshi: Is precisely this implemented?
Basically, not quite, but the differences are minor and outside the
scope of PRR
Martin Duke: Are there any open issues?
No.
Martin: Ship it!
Ian: Are there any objections to progressing this?
Nothing raised, therefore ship it.
Status of ACK Rate Request
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-04
Speaker: Carles Gomez (local)
Time: 15 mins 50/90
Reese: What is the implementation status?
Carles: Only aware of a prototype on FreeBSD
Martin: To what extent do we think data from the QUIC experience with
this is applicable?
Carles: It should be quite applicable
Ian: For the most part it's applicable, but there are some critical
differences with TCP, especially to do with GRO-like aggregation
mechanisms, so the marginal gain might be smaller, but the resultant
tuning might well end up the same.
Martin: We're going to have to make a decision before we have wide
deployment experience. It doesn't have to be as beneficial as QUIC. But
also, are we going to make something in the network very unhappy?
Carles: We've been very careful to not break the basic synchronisation
between sender and receiver.
Gorry: The difference between TCP and QUIC is that there are devices in
the network that try to control the ack rate for TCP, whereas they can't
for QUIC. I'd love to see some data on what happens when one of those is
on the path. Do you have a plan for how you might get that data?
Carles: No, but such data would be great. This targets experimental in
any case, let's see what we can figure out.
Matt: I was just starting an investigation looking at ack interarrival
times and ack-thinning in the network. Luckily I do have a data set,
pcaps for about 4M tests a day, and would like to have an offline chat
about what's there and what can be done.
Updates on Service Affinity Solution for TCP based Application in
Anycast Situation
https://www.ietf.org/archive/id/draft-wang-tcpm-tcp-service-affinity-option-04.html
Speaker: Xueting Li/Wei Wang (remote)
Time: 10 mins 60/90
Ian: Why is this the right layer to be doing this? In particular, since
there has to be authentication here anyway, why not do it inside TLS.
Michael Tuexen: Why a flag in the syn, why not reuse the option? Have
you tested this with some middleboxes? A SYN/FIN exchange is not a
common thing.
Wei?: If this is used in the public network, typically there are no
middleboxes. We did not test all kinds of middlebox.
(some discussion not recorded)
Alexander Clouter: It does feel a bit like this is being done at the
wrong layer, another solution would be to do tunneling between your
service nodes. Was that something that was considered, or is that a
non-option for you?
Wei?: We were looking for a more general mechanism than just HTTP. First
selection is made by a network device, but when the network changes we
want to keep the service affinity, and we want the client to get a real
address to connect to the server.
Yoshi: I have some security concerns with this draft, but are the
security mechanisms mandatory? Packet injection looks really scary.
Wei?: We have had some conversations about security, and we are told
there is no simple solution. We are hoping for some assistance over
that.
Lars: We have seen presentation of this draft at several IETFs, with
similar concerns each time. I wonder if we have reached the end of the
line, as I'm not seeing progression.
Michael: I don't think we need an RFC for this, but it could be done as
an errata for 5961, basically the Linux implementation has changed the
condition to mitigate injection attacks there. Then there are IPR
claims, how does that relate?
Yoshi: I appreciate this presentation. Is this only applicable to a
syn-ack?
Christian: We actually go further in our paper, but here we mainly focus
on the final ack.
Yoshi: I wonder if there is a mitigation that does not use statistics?
Christian: The most efficient approach appears to be tracking how many
bytes have already been acknowledged, all the other approaches seem
worse.
Gorry: I was wondering if you intend to write a draft, or if it should
be handled as an errata. Thanks for the presentation, and lets figure
out how to document it.
Christian: We have no experience on how to address this kind of issue,
but if you so recommend we can write a draft.
Kyle: I suspect that this TLS is not immune to this attack, injection
prior to the exchange is probably not an issue that the TLS developers
considered.
Yoshi: A draft would be great.