* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tcpm Status Pages

TCP Maintenance and Minor Extensions (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2004-Feb-05 —  
Chairs
 
 
 


IETF-99 tcpm minutes

Session 2017-07-17 0930-1200: Karlin I/II - Audio stream - tcpm chatroom

Minutes

minutes-99-tcpm-00 minutes



          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.
          
          



Generated from PyHt script /wg/tcpm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -