* 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: Martin Duke, Magnus Westerlund | 2004-Feb-05 —  
Chairs
 
 
 


IETF-69 tcpm minutes

Slides

These are also available from the materials page:
tcpsecure
ecnsyn (pdf)
ecnsyn (ppt)
frto
1323bis
ack congestion control (pdf)
ack congestion control (ppt)
cwv (pdf)
cwv (ppt)
early retransmit
receiver cheating (pdf)
receiver cheating (ppt)

Minutes




          TCPM Meeting - IETF 69
          Chicago, IL, USA
          Thu, July 26 2007, 1300-1500
          
          TCPM + TCP-AUTH Design Team Status
          
            + Anti-spoof: will be RFC 4653 very soon
          
            + Syn-flood: in the RFC editor's queue
          
            + Soft errors: Fernando to rev for minor things, but basically
              passed wglc and we have consensus
          
            + 2581bis: need implementors' input for an implementation report,
              which is holding up this document right now
          
              Sally: when I'm talking later about congestion window validation
              might recommend sentence change in 2581bis
          
              Mark: Yes.
          
            + User timeout: will do WGLC, consider it now, so read now!
          
            + ICMP attacks: expect rev soon
          
            + Proposals for experimental congestion control schemes to be
              undertaken by this WG.
          
              See Lars' ION.
          
              IETF will receive an external report on such proposals from the
              IRTF's ICCRG.  This report will focus on safety.
          
            + TCP-AUTH design team
          
              WG consensus to take on a replacement for the MD5 option.
          
              Design team reconciling two documents, making good progress and
              expect a draft by Labor Day.
          
          tcpsecure
          draft-ietf-tcpm-tcpsecure-08.txt
          
            + summary of changes: clarification on data injection, and
              usefulness in spoofed FIN-special treatment because trying to
              close connection, lots of editorial fixes.
          
            + main open issue: level of recommendations for mitigations
          
              all of mitigations labeled as SHOULD, but has been questioned
          
              change any to MUST, SHOULD, MAY?
          
              Mark notes we NEED INPUT as the question has been hanging out
              for a while.
          
              Suggestion on list: reset and syn baked enough to be SHOULDs,
              but data injection mitigation not as baked, perhaps MAY?
          
              Touch: comfortable w/data protections being MAY.  Ok with SHOULD
              for SYN/FIN but need to be explained (with 2119 required
              explanation).  "If situation of RFC is something care about AND
              not in a position to deploy appropriate security protections
              with real confidence (ipsec, md5 or successor, ...)".  At the
              end of day, mitigations in this draft are not required for every
              implementation.
          
              Ted/nohat: works other way.  If we make something a SHOULD
              implementors
              need to have a good reason not to do it.
          
              Touch: Then should be MAY.  Recommend in non-2119 language that
              router vendors or class of users deploy.  But, this is not
              appropriate to require everywhere unless reason not to put in.
              level of complexity.  If you need protection you need real
              protection and this is not it.
          
              Anantha: my understanding of SHOULD is that if someone doesn't
              want to do so, they need not do it.  Thought SHOULD covers that.
          
              Ted: it's the default we aretalking about.  SHOULD ought to be
              done unless a good reason not to.  I think SYN/RST should be
              SHOULDs.  I think data shold be MAY because I am less sure about
              it.  That's my personal opinion.
          
              Lars: hum on whether people feel strongly about different
              recommendation for differnt mitigations, then all
              MUST/SHOULD/MAY, then if should do different ones.
          
              Mark: different course of action, get MUST out of way.
          
              cperk: not hearing anyone arguing for MUST.
          
              Mark: hum is MUST.  No response.
          
              Mark: Hum for all three SHOULDs.  Almost no response.  Hum for
              SYN/RST SHOULDs and data injection MAY.  Mild response.  Hum for
              all MAYs.  Mild response.
          
              No big consensus.  Last a tad more, but no overwhelming
              consensus.
          
              [ Accoustics really made hums impossible, the "visual hum" below is
                somewhat clearer.. -- Ted]
          
              Suggestion: WGLC, and if have heart attack, find out there.  We
              have an absence of strong consensus to change document to which
              most people agree.
          
              Joe: I object to that.  Apathy, or ignorance or both should not
              cause whatever got into doc to this point move forward.
          
              Anantha: to comment on Joe's comment on ignorance or apathy.
              We're on version 8 and have been discussing this for two years.
              There is neither ignorance or apathy, it's the way it is.
          
              Proposal from Lars: hum on whether group trusts chairs to make a
              decision?
          
              The proposal was rejected by all, including the chairs.
          
              Lars, trying with hands:
          
                all SHOULDs: 4
                two SHOULDs and a MAY: 8
                all MAYs: 3
          
          Adding Explicit Congestion Notification (ECN) Capability to TCP's
            SYN/ACK Packets
          draft-ietf-tcpm-ecnsyn-02.txt
          
              + Goal: to add ECN to tcp syn/ack to avoid retransmission timeout when
              syn/ack would have been dropped
          
              + Benefits shown in a sigcomm 2005 paper (high for some web traffic).
          
              + Simulations for 3 variants shown: plain ECN, ECN+ (syn/ack is ECN
                capable), ECN/wait (with add'l rtt wait upon a CE notification).
          
                  Results:
                      as congestion increases, more packets dropped, not many marked
                      difference in variants doesnt change # dropped
                      ECN+, ECN/wait show same benefit
          
                  So, no danger of congestion collapse, or increase in drop rate or
                  change in aggregate congestion levels if don't wait RTT.
          
              + Conclusion: no danger and ecn/wait not compelling
          
              + Next steps: can we move forward, or more simulations or what?
          
              Mark: In March/06 I wish I hadn't held up so long.  Like the
              simulations, like the data.  My argument about response was always
              about consistency of response when TCP only had one thing
              outstanding.  I'm happy either way, but don't think it should be
              held up and go forward.  Vote for adding RTT, for consistency, but
              am swayed by evidence that not a big deal
          
              Lars: have you looked at how firewalls/nats behave that might see
              packets?  Was to go for proposed, right?
          
              Sally: Don't think we have looked at it.  Microsoft folks reported
              at last meeting about middleboxes and ECN, and why ECN is not on by
              default.  Would assume this also applies to syn packets, but don't
              know.
          
              Murari, Microsoft:  most of the guys that crash, would crash either
              way so no worse than ECN.
          
              Gorry: what do you think normal response should be if regard CE
              packet as lost.  Recalculate all timers?
          
              Mark: what do current standards say about what do?  Initial RTO is 3
              sec.  So, this is a big win, even if wait RTT, over default.
          
              Anantha: to follow up on ECN thing.  Good idea to post question on
              the BEHAVE WG or something.  Get more responses from correct
              community.
          
              Ted: in absence of strong objection, sounds like last couple of
              impediments to take to last call have been addressed.  Anyone have
              big heartburn.  Going to last call.
          
              [Nope.]
          
          Advancing RFC 4138
          draft-ietf-tcpm-rfc4138bis-00.txt
          draft-kojo-tcpm-frto-eval-00.txt
          
              + Usually spurious retransmissions are due to delay spikes on
                wireless, or link-layer recovery or bw variation
          
              + F-RTO made an Experimental RFC a couple of years ago.  now a
                couple of impl have been deployed
          
              + Eval-00 draft has data.
          
              + F-RTO now default in Vista
          
              + Revising RFC4138 into PS
          
              + Specify base alg in TCP
              + Left out following as experiments: F-RTO with SCTP and
              SACK-enhancement
          
              + Proposal for Response to FRTO identified spurious retransmission:
                simple only in this doc, others would be left to separate RFCs
          
              Mark: at this point the proposal on table is to take F-RTO as PS
              what need to hear from WG, is opinion.  Is the experience good
              enough.  Pasi and co-authors sufficient?
          
              Read two documents and send comments to list.
          
          Revision of RFC 1323
          draft-borman-1323bis-00.txt
          
              + what's different from current 1323, where stand and outstanding
              issues will go through quickly.
          
              + see slides
          
              Touch: Good idea.  Encourage people that clocks in tcp are neither
              absolute nor correlated to each other on same machine anyway.
              TCP is not a real time system; hesistate to recommend that
              this provides any sort of protection but avoids an obvious
              hole/pitfall.  Not so much protection as avoiding pitfall.  Goes for
              a lot of other things.  That's the right way to view many of the
              changes in this document.
          
              David: yeah, these raise the lower bound.
          
              + OUTSTANDING ISSUES
                  + Biggest: whether or not to allow timestamps to be enabled
                  later, not at beginning.
          
                  + Should PAWS require DF bit be set?  PAWS only protects first
                  frag.  Can flag & explain, or require.
          
                  + is it worth allowing RTTM from DUPACK?
                      + personal opinion is no.  to do so, requires changes on
                      both ends of connection put something differnet into echo
                      reply to get valid data...
          
              Sally: Did you talk about the problem of changing time constant for
              any RTT for many measurements per RTT?
          
              David: Yes.  But the document only flags as issue.
          
              Touch: On defering timestamps: easy, and NO.  No other tcp option
              can be initialized after the connection starts.  SYN exchange
              determines this... starting after beginning is bad.  Unless the use
              is optional in all packets after use in SYN.
          
              David: agree.
          
              Touch: second one is very important.  PAWS should REQUIRE DF be set.
              Put a sentence in there... people who come up and say, if DF bit is
              set, why use a unique IP ID?  Because sender can't know when you
              send that
              the next packet thru didn't have DF set.  Then a host could reassemble
              stuff that doesn't belong together.  Can't willy-nilly use ID field.
              Good example of impact.
          
              Dave: anyone that has actual text, send some.
          
              Anantha: Should the advertised MSS take into account TCP options?
          
              David: It should not.
          
              Anantha: We do not take options into account in our implementation.
              We
              have seen both behaviors since there seems to be no STD which
              specifies
              correct behavior.
          
              David: We can take it out of the appendix, or write up a one-page
              RFC.  It's not a hard topic if you think about it.  You want to
              avoid IP fragmentation and you get in trouble if you
              one side assumes options in the MSS number, and other does not.
              At time you're generating the packet, don't really KNOW what size
              is.  Can't guarantee it.  The only way to guarantee that sent
              packets are not too big, is to assume other side
              did not acocunt for options.  Decrease MSS based on that assumption
              and then things are guaranteed to fit.
          
              Anantha: That makes sense.  A separate doc also makes sense.
          
              Gorry: If you mandate DF, do you mandate PMTUD?
          
              David: Yes, they do fall together.
          
              David: This was accepted as WG item in TSVWG and moved into here.
              It might be good to get offical hum to say WG item.
          
              Mark: Just looked thru the magic of cvs, and is 1323bis is on TCPM's
              original charter.  Our assumption is that folks are fine with this.
              Assume it's ok, unless people start complaing.  Don't complain now,
              because you'd be eating into Sally's time.
          
          RFC 2861 on TCP Congestion Window Validation
          
              Should we advance CWV (RFC 2861) from experimental to proposed
              standard?
          
              What do real TCPs do?
                - unsure if any implementations follow SHOULD in RFC2581
                - unsure if any using CWV in response to data-limited period
          
              How would you evaluate?
                - better for THIS connection?
                    probably do nothing
                - better if all N connections traversing a congested link do same
                  thing?
          
              Does it matter if CWV moves to PS?
                - Could matter for some implementations
                -It matters for revising TFRC for response to data-limited periods
          
              Anyone used it?  Any opinions?  Say "done due diligence and go home"?
          
              Mark: one place could matter is if congestion window is quite big
              and send burst into net, see loss where you wouldn't have had you
              cut window a bit and slow-started (so sometimes in your advantage).
              But you don't know about this a-priori.  Part of this, the
              data-limited part is implicitly proposed standard already. RFC2581
              explicitly allows TCP to be more conservative than algorithms in
              RFC2581.  This clearly is.
          
              Sally: So essentially, the standard says "may" use.
          
              Mark: Right--we can't fault people for doing it.
          
              Sally: Should we encourage others?
          
              Mark: My opinion: yes.
          
              Murari: [reconstructed] From a congestion control stand point this
              makes total sense to reprobe the bandwidth after idle time. I agreed
              that this is hard to argue against but still doesn't get enabled by
              default due to apps pushing back on this esp the long lived ones.
              Most of these apps already want some sort of a quick start mechanism
              so this would go against that. Ah yes regarding RTT I think my point
              was that most OS's these days have microsecond timer resolution for
              tracking RTTs so the idle period should be carefully chosen such
              that we don't over-react and decay the congestion window. So I
              suggested that we appropriately adjust the idle time interval as
              some "reasonable" multiple of RTT.
          
              re-probe.  The fact that Microsoft hasn't enabled CWV is because of
              pushback for applications.  res using for RTTs these days is fine,
              RTO are not that large depending on how small RTO is, might be
              over-reacting.
          
              Saman Masi?: two apps that would suffer if CWV were applied
                - streaming ovr TCP
                - sending voice over TCP.
              Not that it is a good idea, but two apps.
          
               the thing that bothers me most about CWV is
              that a rate-variable application would actually do better by
              padding its stream -- sending unnecessary data only for the
              purpose of probing the network.
          
              Slmar: to add to this comment: skype... does things to try to
              maintain window during idle periods.
          
              Sally: agree that have to address.
          
              Hands on going to PS?: 6-7
              Opposed: 1
          
          Adding Acknowledgement Congestion Control to TCP
          draft-floyd-tcpm-ackcc-01.txt
          
              Please read draft and give feedback.
          
              DCCP CCID 2 is the basis basis.
              Urgent? no.  Useful? yeah---for asymmetric links.
          
              Do ACK really contribute to congestion?  Sure if some path has
              only ACKs.
          
              If there is data and ACK traffic are the ACKs contributing to
              congestion? Yes, in some ways.  E.g., if drop-tail or red, and
              units of packets.
          
              Feedback?  Should this be work item for TCP (as an experimental
              document)?
          
              Anantha: question on kepalives.  Even though keepalive not part
              of standard mention somewhere... if applies to keepalive
              packets, or no distinciton.  He is confused by the draft.
          
              Sally: should add as a question.
          
              Murari: haven't read, but based on description was going to ask
              about ABC.  Assume sender implements ABC.  That means that if
              get ack for K then we need to pace out data over some intervals
              such that receiving is less bursty.  This is not to slow down,
              but to reduce short term burstiness.
          
              Murari: if link speed is high already pretty good ack ratio.
              most stacks send ack at end of receive DPC.  If get 8 packets,
              only one ack.  For gigabit and higher already see good ack
              ratio.
          
              Sally: current standard says must ack ever 2.
          
              Murari: not possible.
          
              So for high-bw TCPs the ACK interval may be more than 2.  We'd
              love people to look and verify this.
          
              Anantha: love for you to look.  Think most implementations follow
              ack per packet.
          
              Murari: tried to do it, but problem is, in one indication, might
              get 8 packets and we only send after processing incoming
              segments.
          
          Early Retransmit for TCP and SCTP
          draft-allman-tcp-early-rexmt-05.txt
          
              This draft has been around a while.  Should we forget this and
              go away?  Or, finish?
          
              Sometimes we can't use fast retransmit because the congestion
              window is small.
          
              Limited Transmit (RFC3042) helps if you have data to send and
              the receiver's windows allows you to send it.
          
              We have let ER die before.  But people keep asking about it, so
              we're back.
          
              Goal: experimental to gain experience.
          
              Murari: makes sense if sending jumbos (e.g., 16k window looks
              like 2 packets).
          
              Randall Stewart: a while ago we talked about something like
              this, but the idea was to just start a timer, and after RTT and
              a couple 100 ms, just fire off a retransmit.  We never got far,
              but wonder if anyone has ever done anything like that.
          
              Mark: I have heard this idea too.  When the congestion window is
              small, super-fast RTO, basically.  There might be some
              justification for that.  If you would write down, might read and
              say 'OK'.  I'm not knee-jerk opposed, but I also don't think it
              is obviously better than ER.
          
              David Borman: Haven't read the document, but seems like some
              good ideas here, especially in case of not a lot of data to send
              at the end of a connection.  At worst we get a spurious
              retransmission.  Seems like it's a good idea and well worth
              purusing.
          
              Sally: haven't read this version, but read lots of old ones.
              Fine with going to experimental and encouraging simulations.
              Need to look at the worst case, if it isn't there.
          
              Mark: There is a sketch of the worst case.
          
              Sshu?: Recovering more quickly would be good; support effort.
          
              Quick viz hum, go ahead and become TCPM WG item for experimental?
                said yes: 12+; no one opposed
          
          A TCP Test to Allow Senders to Identify Receiver Non-Compliance
          draft-moncaster-tcpm-rcv-cheat-01.txt
          
              2nd time presented.
              Quite a few updates since Prague.
              Simple mechanism to allow sender to test receiver compliance
                regarding ACK generation.
          
              Should we move to a WG item?
          
              This optional test is meant to plug existing hole in TCP, but
              not an ideal solution.  Some sort of transport layer nonce would
              be a better solution.
          
              Mark: I am a little ocnfused whether outside test (a side
              thing), or if it should go into TCP (so we think all TCP
              implementations should do it).
          
              Toby: This is definitely an optional thing that people can choose to
              do.  Assumption is that can trust reciever.  If you feel you cannot,
              here is one way to safely check behavior.
          
              Mark: this is a recommendation to put in to Microsoft and Sun's
              TCP, and perhaps not use all the time?
          
              Toby: A utility to check sort of thing.  Not part of TCP
              standard.  Not part of absolute standard.
          
              cperk: That's what I was going to suggest.  Having a mechanism
              is a good thing and the document is something this WG should do,
              but an informational not a PS.
          
              Mark: what would experiment be?
          
              Joe: Not proposing a change to TCP, as a mechanism to test for
              right thing.  Not even a protocol at that point, but a procedure
              for testing things might be a BCP at some level.  If test, here
              is a good way.
          
              Joe: If really don't trust info at other end
              use proper security, nonce is not proper security.
          
              Ted: IPsec wouldn't solve problem.
              Joe: neither would nonce.
              Ted: this is like ECN nonce, sending real data and really saw
                packet acked.
              Joe: ah
          
              Murari: what resource are you trying to protect?  Avoid
              committing resources on sender because the receiver is
              malicious?
          
              Toby: yes
          
              Murari: A better way to do it is to shrink window to zero and
              do zero-window probing, if really malicious, wouldn't violate
              protocol, would inflate and sit there.
          
              Toby: There are cases where not extremely malicious receivers
              can gain something if slightly preturbing the ACK stream.
          
              Murari: agree, but don't solve server resources.
          
              Mark: Not sure I see this as IETF work.  There are a bazillion
              conormance tests for TCP.  Sally wrote a bunch in tbit.  These
              are all very complex and I am not sure this is the right thing
              for the IETF to work on.  Also, the tbit tests aged poorly and
              had to be updated and so this could be quite a big new task to
              keep a set of tests current and useful.
          
              Bob Briscoe: slightly disagree w/coauthor that only test suite
              thing.  The trouble is getting mis-behaving receivers to connect
              to your test server.  Goal is to write something with IETF stamp
              of approval that is safe for a server / sending TCP to do in
              order to test receivers that it thought were non-compliant.  In
              addition, I can imagine test suites using receivers built to be
              non-compliant, but not sure how to get receivers to come to
              them.
          
              Sally: tbit test, done from web server.  Testing their TCP.
              Usefulness of test depends on population of server.
          
          



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