* 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 —  

IETF-100 tcpm minutes

Session 2017-11-16 0930-1200: Olivia - Audio stream - tcpm chatroom


minutes-100-tcpm-00 minute

          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.
          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
          Working Group Items
          TCP Alternative Backoff with ECN (ABE)
          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
          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
          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
          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
          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
          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
          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
          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. .
          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
          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)
          Speaker: Yuchung Cheng
          Gorry: Regarding middleboxes (slide 9): What was invalid? Just random
          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
          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
          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
          Speaker: Marcelo Bagnulo / Yoshifumi Nishida
          Lars: Why can we not just use 1 bit to signal a larger sequence number
          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.

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