Minutes IETF100: tcpm
minutes-100-tcpm-00

TCPM meeting, IETF-100, Singapore
Thursday, November 16, 2017, 9:30 - 12:00
Chairs: Yoshifumi Nishida, Michael Scharf, Michael Tuexen (remote)
Note taker: Gorry Fairhurst
Jabber scribe: Mirja Kuehlewind

WG Status updates
Speaker: Chairs
*****************

Status of drafts reviewed by TCPM Chairs.

draft-bonaventure-mptcp-converters
Mirja (speaking as AD for TCPM and MPTCP): I would like to see a use-case for
this document. Is the main use mptcp? David: As TCPINC chair: I back the
question mark on TCPINC, I would not try to make this draft applicable to
TCPINC. That would make a man in the middle attack. Mirja: The endpoints
collaborate. David: I will look at this. Chairs: We will run an adoption call
on the mailing list and look for feedback

Working Group Items
===================

TCP Alternative Backoff with ECN (ABE)
draft-ietf-tcpm-alternativebackoff-ecn-02
Speaker: Naeem Khademi
*****************************************

Gorry (as TSVWG chair): The proposal is the right thing to for SCTP.
Unfortunately, the ECN spec for SCTP never got adopted. Praveeen: Recommended
value is 0.8? Are the implementations using 0.8? Naeem: Yes Praveen: Has there
been any work to explore what happens after applying the feedabck using 0.8 in
the following RTT. Should it reduce more after loss? Praveen: You don't known
if there is AQM. Gorry: This is only for ECN marks. If there is loss, the
standard congestion control applies. Praveen: Still, one could get more ECN
marks. Mirja: What happens if there are losses and ECN marks? Gorry: I think
the loss reaction is taken. Mirja: Clarify the behavior if there is both loss
and ECN marks. Naeem: With ECN, one would only react once per RTT. I will check
the patches. David: The scenario is ECN CE-mark in one RTT, loss in the next
RTT. Michael Welzl: Question: This is more about the behavior ECN, than about
ABE. David: As long as ECN and loss reaction is the same, it does not matter.
Gorry: We have to read the code. ?: Sally's papers on ECN are very clear on
that Lawrence: The FreeBSD code does not apply any additional backoff. David: I
have reviewed this. Most of my comments are editorial. My obverservation is
that the text focuses a lot on recent AQMs only, and not on what else might be
out there.

ECN++ Updates
draft-ietf-tcpm-generalized-ecn-02
Speaker: Marcelo Bagnulo
**************************************

The WG mailing list was asked about to handle pure ACKs.
Bob: The AccECN option is needed to get bytes. If a middlebox strips this then
we lack info. Michael Scharf (from the floor mic): I would like to understand
the differences when AccECN is used and the dependencies. I wonder if we need
to deal with all possibilities. draft contains this. Could simplify the
document?

The current ID defines when AccECN is negotiated and when it is not. There
could be editorial work, we could separate the two documents.

Michael: Even for the SYN we can discuss whether it matters when we see a
CE-mark in the SYN. Marcelo:  This may be more pure. Mirja has made a statement
that you should not ignore the CE signal. Gorry: the current doc is a little
hard to read. I think we need to decide if the document would be simpler just
specifying the one case, either version requires a change to the sender. So why
not just say we do this for one case. Mirja: The document would be simpler if
you only want to use AccECN. Marcelo: We could do two descriptions for AccECN
and non-AccECN back to back. Mirja: We could just say only if AccECN is
negotiated, then the rest of the process is Michael Scharf: I don't buy the
argument that for the SYN you really want need to care about CE marking. I have
seen this IETF one working group and one research group discussing very
aggressive behavior, including not reacting to loss. Then why do we need to
react to CE in the SYN? Mirja: The second point is do we care if the SYN is
marked. Mirja: As soon as we see marking on a SYN - we have real indication of
congestion.

Marcelo: If we believe in AccECN as the way forward, the draft could state the
case only for AccECN and simplify the draft. Bob: If the other end does not
support AccECN, then you still need to say what happens. Mracelo: If the other
endpoint doesn't support AccECN the remote will still respond reporting the
CE-mark received. Bob: I am Ok to being more liberal to loss, but I think the
SYN is a different case. There needs to be a response to marking on a SYN, that
was the cause of congestion collapse in the Internet. We need to have a loss.
Michael Scharf: Do we care about the ECN CE-mark? (a drop is VERY different).

Gorry: I will send my review, this may help for the next rev.
Marcelo: I will try to update the draft to focus on acc ecn case only. Is
anybody against it? No one spoke up.

Presentation on measuring ECN++.
Ingemar: This is from the client towards the mobile network. Is it the mobile
network? It could be the modem chipset that makes the difference? (on the
mobile device). Stuart: You suggest that mobile handset may be at fault?
Marcelo: Not so, the hardware is the same and works in the other cases. Mirja:
Did you also test on non-mobile cases. Marcelo: Yes on planet lab. Marcelo: The
RFC5562 spec appears to be not being used. Bob: The RFC5562 draft is odd.
<explained the exchange>. Marcelo: The present ID plans to obsolete this.
Stuart: I wonder what you hoped to achieve with paper? - I am concerned by the
message of people reading the paper title only. Praveen: I see the paper as
good news, saying it is fine to deploy

AccECN update
draft-ietf-tcpm-accurate-ecn-04
Speaker: Bob Briscoe
*******************************

Michael (from the floor): Regarding the wording on "deployment": I owe you some
text, I will send. How could a standards-track version of this be negotiated?
Bob: The counter start value could indicate a different version, the current
version allows such a start. Michael: I'd like to plan for the final transition
to proposed standard, as this consumes a bit in the TCP header. Mirja: i think
we could change the implementation. Michael: Let's plan ahead. Chairs: We will
review this. We are looking for reviewers for this. Praveen: I will review.
What sort of offload are you speaking about? Are you talking about full TCP
offload? Windows required vendors of LRO not to group ACKs togther. I can send
info about how this works. Mirja: I think this is mainly ACK aggregation.

Lars: On general ECN, this is also being talked about with relation to QUIC,
but decisions on how to handle ECN in the first release need to be taken this
year. Bob: There is a discussion about this in the IETF today.

TLP RACK Update (Remote Presentation)
draft-ietf-tcpm-rack-01
Speaker: Yuchung Cheng
*************************************

Gorry: Regarding middleboxes (slide 9): What was invalid? Just random numbers?
Yuchung: There is an offset in the response, which makes them invalid.

Praveen: You show reodering is a theoretical problem, what happens in practice.
We try very hard to minimise reordering. Is this a real problem? Yuchung: All
data shows that a quarter of the RTT seems sufficient. Reordering seems mainly
be caused by FEC. Praveen: Is there data for really low latency links (10's
usecs), can we elminate fine grain timers? Yuchung: We don't really need
high-resolution timers even in data centers. It is still better than DUPACKs.
Praveen: Packet-based detection is not that complicated. How come 70% of
transcations recovered by timers? Yuchung: Most http server responses are a
single packet - there is not much else you can do. Ilpo: There are also other
cases for Linux that have this problem. It is a pretty typical number. This is
about tail losses at the end of the window. Yuchung: HTTP/2 lowers the number
due to pipelining. Ingemar: You can expect reordering in future 5G systems...
this is important to consider. Yuchung: We can do a reorder-window, e.g. per
route.

Other Items
===========

Extending TCP sequence number and TCP receive window
draft-bagnulo-tcpm-esn-00
Speaker: Marcelo Bagnulo / Yoshifumi Nishida
*****************************************************

Lars: Why can we not just use 1 bit to signal a larger sequence number space?
Stuart: I think Lars suggests the sequence space works in segments, not bytes
(as an option). Marcelo: We could think about that.

Michael Scharf (from room): As a note, the TSOption is one of the candidates
that we do not need to have in SYN... that's not (necessarily) needed in the
SYN. Marcelo: The nice thing about using the TSoption is that the Extended
Sequence Number simply replaces the functionality of PAWS, and this benefits
from using an existing field supported on the wire. Michael Scharf (from room):
The TSopt is also used for measuring RTT by monitoring tools. Most systems
sample, they often do not see the SYN - it is commonly deployed as a monitoring
system. Yoshifumi (from room): This is something to explore.

Praveen: The default recieve window seems OK for current use. You could run
multiple sessions to run faster. I worry about modifications to SACK and other
things in the network that may cause this to break. We have been hurt in the
past. Marcelo: I would be happy to look for data. Does it make sense to work on
this? Lars: QUIC is being designed and could have solutions that scale to high
speeds. This seems complicated for what it gets you? Michael: I think we are
allowed to think about how to maintain TCP's usability (other protocols may not
need to do this). This problem seems to mainly matter for very high-speed links
(40G, 100G). Thus, we also need to think about off-loading as a key question.
Mirja: Why not scale everyting? If there is a recieve window scaling, we also
scale the sequence number (as proposed by lars). Laurence Stuart: Could you
just use multipath TCP?

Updates on Windows TCP
Speaker: Praveen Balasubramanian
********************************

Jana: What data do you send in the connections?
Praveen: We connect ordered in time (if there is a real problem we don't try to
resume). Stuart: What does "network" mean on the slide? What happens if a
particular site I visit has a box on path that I visit from multiple starting
networks - do I think the networks are all broken? Praveen: Windows has a way
to identify unique networks. Yes, we try to explore problems near the sender.
Patrik: Firefox has a lot of mitigation strategies. The one case that kills us:
when TFO is negotiated, then TLS 1.3 has a high error rate? Are there other
things you cna do? Can you tell us what the timeout is on slide 5? Praveen: The
full data timeout is when ... . We do not have experience yet with TLS 1.3.
Jana: Thanks for doing this. I'm interested how much of this (timeouts) is
linked to other problems, rather than just TFO. Praveen: We will look for these
numbers. Stuart: Thanks also. It is important to make TFO safely (not
necessarily a priority to make it work everywere).

Meeting closed.