Minutes IETF99: tcpm
minutes-99-tcpm-00

TCP Maintenance and Minor Extensions (TCPM)
IETF 99, Prague
Monday, July 17, 2017, 9:30-12:00 (CEST)
Chairs: Michael Scharf & Michael Tuexen
Note Taker: Gorry Fairhurst

WG status
=========

TCPM working group status
Chairs

draft-ietf-tcpm-dctcp: I-D has been approved by IESG
draft-ietf-tcpm-cubic: There has been an update after WGLC

Working group items
===================

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

Michael Tuexen (from floor): I'm OK with ECN for SCTP to be added when this is
specified in an RFC Michael Tuexen: You cannot modify "FlightSize". Naeem
Khademi: We could say CWND is modified? Bob Briscoe: What does the
implementation do? Naeem Khademi: It uses CWND.

Chairs: How many have read this document? (about 5)
Chairs: Who would review this document?
Reviewers: David Black, Lawrence, Randal Stewart, Roland Bless.

Chairs: Document will progress following publications being requested for ECN
Experimentation, likely WGLC at next meeting.

More Accurate ECN Feedback in TCP (draft-ietf-tcpm-accurate-ecn)
Bob Briscoe

Mirja Kuehlewind: There may still be cases where the AccECN option is needed to
be implemented/used. Bob: In a Datacenter you still may need the field (in case
you get seq. number wrap).

Bob: The generation of AccECN ACKs with the option can happen in bursts.
Andrew McGregor: If the RTT is really small.
Bob: Receiver doesn't know what the timer resolution is.
Andrew McGregor: Producing that many more ACKs at some time is going to cause
issues with sending. Accross the Internet, this is no issue - if you know the
destination is within the building then you could do something different. Can a
receiver signal to say something is different. Gorry: The feedback option could
be used to signal this. Mirja: If we say "SHOULD" this is maybe enough, the
information is fuzzy, and the sender has to deal with this feedback. At the
start of a flow the receiver typically ACKs each packet (where it matters).
Bob: We can say try to do this during slow start. Michael Scharf (floor mic):
There are some statements on the "success criteria" for the protocol. I think
the success could be that the protocol is finally deployed.

Michael Tuexen: Summary slide with overview of options for Nonce Sum (NS) bit
reassignment TSVWG would trigger unassignment of the NS field within the TCP
header TCPM now needs to decide what it would like to do

Michael T.: Are there futher options?
Mirja: We could also think of not-reassigning until the experiment is over.
Gorry: We could rename the field as "network signaling" (NS) to preserve the
semantics of the field. Michael Scharf (from the floor): We should be aware
that this discussion has impact on all textbooks introducing the TCP header.
Lars: I only care about the unassigning bit. (Leave it unassigned and leave it
for the experiment to conclude). Bob: This negotiates a new feedback experiment
for TCP. Lars: An IANA registration does not help. Bob: It helps some people
who look. Michael Scharf (from the floor): We can not think about "bad"
implementors. From my experience, "bad" implementers don't care about IANA.
Bob: The problem with (a) is that the IESG may not do what we think. Mirja: I
think the right thing will happen.

Chairs: Does the WG see value in re-assigning the de-allocated NS field to
AccECN? Humm for (decent) Humm against (few) There is strong but not unanimous
consensus in the room for assigning the codepoint.

ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets
(draft-bagnulo-tcpm-generalized-ecn) Marcelo Bagnulo

Mirja: If the ACK is not marked: If you loose some ACKs, this costs little
performance penalty. Marcelo: I think we need to find out whether current
deployed servers send an echo back from pure ACKs marked as CE. Mirja: That is
for sure useful. If you mark a packet and have no feedback, that's not
something in general to recommend. Marcelo: I will look for data. Could we CC
control the ACKs? Jana: Don't use congestion-controlled ACKs, it is really
complicated. You are very close to shooting yourself in the foot. Marcelo: I
think it is useful to mark ACKs (to avoid drop), and get feedback on
congestion. Jana: This is making an ECN signal that is not on data bytes. If
you only send data ACKs this is the rate*40B or so. Marcelo: We want to avoid
ACKs getting lost. Mirja: I think there are corner cases where a low rate of
ACKs is useful. A really low rate may be important. Bob: In some cases reducing
cwnd also reduces the rate. Jana: The problem here is the marks reflect the
other sides cwnd, not the senders. If you reduce your cwnd (and may not be
using), this may be irrelevent. Bob: This may be OK. In idle connection, you
reduce your cwnd. If you later start to send, you change what you send. Jana:
You can track more state to do this. It still seems odd that you reduce your
cwnd, because your ACKs were marked. Marcelo: If we send data, there is a
useful update. Jana: Agree, we can know this and it is useful. Most common
deployments do not reduce cwnd after idle. Pacing after idle is useful. The ACK
rate is proprotional to the sending rate, but reducing cwnd seems odd. Marcelo:
Detect sending pure ACKs, then don't reduce cwnd. Jana: Suppose we send 1000
packet, then send one packet. Mirja: The problem is cwnd is a time-dependent
value, reducing perhaps to cwnd. Do not send a marking, if you do not have
feedback. Gorry: I see a continuous stream of CE marks on ACKs simply drives
cwnd to 1 segment, this WG discussed what to do when a TCP sender sensd
litte/nothing in RFC7661 that applies here. Bob: That is cited.

Mirja: Loss due to path-change is a generic problem.
Mirja (relaying Bob): You can't detect if you are loosing pure acks.

Michael Scharf (as chair): Is there a cross-dependency between AccECN and this.
Are there combinations where the two are deployed together? Should they be
published together? Are there cases where someone would implement just one of
these two? Mirja: There is a dependency of ECN++ and AccECN in one direction,
but not the other way around. One of the big advantages is doing this on the
SYN. Joao: There are (middle)boxes that parse on the ECT field with ECT(1) and
then when the flow sets CE, anycast can generate a reset, because the path to
routing the final box is changed. Andrew: If you hash on the entire byte and
use ECN this causes problems. Most boxes also seem to have configurations that
also allow this to be done the correct way. People should get it right. Andrew:
I think you may wish to do ECN++ because you simplify the implementation. I
think the benefit of setting ECT on the SYN is the biggest, I think the
combination where AccECN and ECN++ are both implemented is important. Joao: The
"whole-byte" processing is a hurdle for deployment of ECN. Mirja: I think the
point of "byte-based" actions has is true of all ECN use cases.

Individual documents
====================

TCP Low Latency Option (draft-wang-tcpm-low-latency-opt)
Wei Wang

Bob Briscoe: I read this carefully. I will send a review. I support the goals,
but do not support the way you starting. Does this have benefit for the whole
Internet? Once you know the RTT you know a lot about the flow. Wei: The main
reason is that within a DC you have prior knowledge of some params. Bob
Briscoe: It may be OK to initialise this, but once you know the RTT you can be
sure what is appropriate. Jerry Chu: Why do we have max RTO? Neil Cardwell: You
do not know what the other ends delayed ACK policy. Bob Briscoe: We could agree
a standard part of the RTT to be used for these params. Neil: It's often timer
granulaity of the end hosts. Brian Trammel: This seems dangerous to do this in
an unauthenticated header. Gorry: An on-path device can do anything. Neil: It's
still got the RTT term in the definition. Andrew McGregor: I think we can find
a way to do this that just says the time-granuality. Michael Scharf (from the
Floor): Can there be a mode that does this after the SYN, without using the
scarce SYN option space? Mirja: I think you do not need to do this in the
handshake. Jana: It seems like telling the timer granuality is too much info. I
like the idea of utlising the RTT as an input. This seems like we need to send
a constant. Bob: How do you configure this? (I think the constant is wrong).
Jerry Chu: We have been using this and it is useful. Neil: The Max ACK delay
talks a lot about how you see the whole TCP processing time. Jana: I don't
think we should signal granuality. Mirja: You want something that depends on
granuality and RTT. Neil: The two sides may have different RTTs. David: This
mechanism is in use in datacentres, where you actually know what is going on.
There needs to be some way to check what is actually the case - RTT helps give
you the indication that things are not as you expect, and how to back-out from
this case. Jonathan Looney: I think this is something we should do. Mirja: I
think if you have prior knowledge, the data centre case is less interesting.
Neil: In large cloud environments with stacks with different versions and many
vendors this may be useful. Jana: The problem is interesting - and we can hash
things out. Michael Scharf (chairs): Please look at the feedback and come back
to the WG.

TCB Control Block Sharing (draft-touch-tcpm-2140bis)
Safiqul Islam

Michael Scharf (chair): We ran an adoption call on the mailing list. We would
like to know if there is interest?

Andrew: I did not comment, because I did not see it. It is sometimes
problematic and sometimes safe. Documenting the basics has value.

Michael Scharf (Chair): Is there a belief that this is worthwhile to document?
(10 people) - Are there objections? (none) There is a sense in the toom that
there is value in documenting this behaviour. Michael Scharf (chair): What
status should this be?

Gorry: I think we can make this a BCP if lots of people sign-up to what this
does. Safiqul: We could split the document into an informational appendix and
short BCP line. Jana: I am not sure I am so excited to make this BCP, writing
BCP based on deployed practice is not so useful. Michael Welzl (remote): The
idea is to get clear recommendations about the practice. I think if we just
hand wave about what is done that's not so useful. If we find "safe" things
that we can decide as a WG. Jana: How do we know what is safe? If they are
deployed and used? Things deployed are safe ... Michael Welzl (remote): Some
things are not safe. Jana: The most useful part is the documenting the
behaviour. Andrew: There seems support for publication.

Michael Scharf (Chair): Is there intention if this can become a BCP? (4 people)
- Are there objections to publication as a BCP? (none)

There is value in adopting this work.

The meeting concluded at noon.