Subject: Re: [tsvwg] FW: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Fri, 1 Nov 2013 13:00:40 +0100

Hi,

While I  agree that the handling of ssthresh after idle time is a generic
issue left underspecified in both TCP and SCTP CC,
then I would like to stress that it is of significant bigger importance
for long-lived (data path changing) MH SCTP than it is for short-lived
non-multipath TCP.
But with emerging, supposedly long-lived, multipath TCP, perhaps the issue
will get more awareness also outside of the MH SCTP realm.

Saying for SCTP (and then also for SCTP PF, but I do not believe that the
discussion in any way is particular to PF-SCTP)
that a successful HB will be allowed to increment the CWND (as if it was a
successful data packet) -
then strictly speaking such should follow ABC semantics - shouldn't ?
(This in practice may give a full PMTU more due to how
CWND limits are implemented, but there is still a difference in the
formulation).

The other issue then is what the impact of a lost HB should be ? If we
model
successful HBs as Data T3 retransmissions, the consequence would be also
to have failing HBs impact CWND and ssthresh. This however makes it even
more critical to have the
ssthresh handling during idle be clarified. Otherwise a temporary network
failure could cause ssthresh on an idle
path, which observes a HB failure, to go down to IW and have data
transmission on the path forever remain in Congestion Avoidance.

There are equivalent problems with ssthresh in the situation where a
single T3-retransmissions send on alternative path is lost today in SCTP
(non CMT-SCTP).
But TLP or other mechanisms may amend this situation. I suppose that we
would not like such mechanisms to have to be run to qualify HB failures.
If so we should either be very careful with letting CWND or ssthresh be
impacted by HBs or adequately address the sshresh update issue.

A nit:

Speaking of ack clocks and retransmission data, then PF-SCTP clarifies
PF-SCTP in saying that from a path counter availability perspective
one cannot trust SACKs on data that have been sent on multiple paths to
clear the IP Path counter. I note that from a CC perspective, however,
then the approach is
to have the data be accredited to the CWND (ABC count) on the path on
which it was last sent (this I suppose also follows CuCv2 principles of
CMT-SCTP). Possibly this could be clarified in
PF-SCTP draft text:

   8.  ACKs for retransmissions do not transition a PF destination back
       to Active state, since a sender cannot disambiguate whether the
       ack was for the original transmission or the retransmission(s).

BR, Karen

PS:
Sorry for the long wait. I have been away on a vacation that transformed
itself to illness...
See you in a few days, I hope.

> -----Original Message-----
> From: Yoshifumi Nishida [mailto:[email-masked]]
> Sent: 15. oktober 2013 04:23
> To: Karen E. Egede Nielsen
> Cc: Randall Stewart; Yoshifumi Nishida; Michael Tuexen; Salvatore Loreto
> Subject: Re: FW: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt
>
> Hi Karen,
>
> As you suggest, I think we'll need to think about how to set ssthresh
properly
> after idle time and it will be an important topic for CC.
> But, I'm thinking this will be outside of SCTP as it is more generic
issue.
> Once we get some consensus on it, I think SCTP (and PF) should follow
the
> rule.
>
> For the second problem you mentioned, yes. it's related to PF.
> The current PF draft suggests 2 MTU  may be used as cwnd after the
receipt
> of HB-ACK.
> This means we're treating HB packets just like data packets.
>
> In case of HB packet loss, in the current draft states cwnd should be
set to 1
> or 2 MTU after successful HB-ACK in PF destination.
> So, we basically don't care the number of failure or success of HBs and
just
> try to use conservative value as cwnd.
> I guess this might be a point for discussion. If you have some comments
on
> the logic, please let me know.
>
> Thanks,
> --
> Yoshifumi
>
>
> On Mon, Oct 14, 2013 at 2:41 AM, Karen E. Egede Nielsen
> <[email-masked]> wrote:
> > Hi,
> >
> > For SCTP, and for quick failover in particular, then the ssthresh used
> > when reverting to a previous failed path is of great significance.
> >
> > In our implementations today we leave ssthresh where it was. However
> > we are looking to increase it up to infinite after RTO idle time.
> > Depending on where the CWND is left. I.e., in our implementation CWND
> > is decreased/respectively increased exponentially per RTO time idle
> > time. Ssthresh should not be boosted to infinite as long as CWND is
> > above IW.
> >
> > I think this is one of the issues that one should seek to clarify in
SCTP.
> > Possibly it could be done in connection with the PF draft (quick
> > failover).
> > But the issue is more generic, I agree.
> >
> > The other issue is the extent to which failing HBs, and conversely
> > successful HBs, should influence the CWND. This is very relevant for
> > the PF draft.
> >
> > TCP keep-alives do not impact the CWND, but then the TCP keep-alives
> > carry no data and are, typically, send very infrequently.
> > The standard path monitoring HBs of RFC4960 are also send
> > infrequently, as far as I know, and it makes sense for them not to
> > influence the CWND - likely it would have no significance anyway.
> > I.e., the effect would have faded off when the path starts to be used
> > for data. (Except for when such successful HBs result in switchbacks)
> >
> > With the more aggressive HBs of things are different - or are they
> > different really ? - still the HBs are sent relatively infrequent and
> > drop of a HB may very well be the result of a single packet loss (i.e.
> > , not be congestion related) and anyway the HBs could not compete for
> CWND.
> > On the other hand the HBs look a lot like T3-retransmission of DATA.
> >
> > What is your feeling - ? - should failing HBs on a PF path keep the
> > CWND down and conversely should a successful HB increase the CWND in
> > accordance with ABC ?
> > Then still after subsequent idle time, the CWND and ssthresh should be
> > adjusted accordingly.
> >
> > Thanks,
> >
> > BR, Karen
> >
> >
> >
> >> -----Original Message-----
> >> From: Karen E. Egede Nielsen [mailto:[email-masked]]
> >> Sent: 14. oktober 2013 11:10
> >> To: 'Yuchung Cheng'; 'Gorry Fairhurst'
> >> Cc: 'McAlpine, Gary'; [email-masked]'
> >> Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt
> >>
> >> Hi,
> >>
> >> > >
> >> > > I see the problem with pinning cwnd to a low ssthresh - and I'd
> >> > > be happy to collaborate to write a draft on fixing this. I
> >> > > offered to collaborate to write something, that's still open. It
> >> > > can be a big issue for apps that are not even rate-limited in any
way.
> >> > >
> >> > > However, it's not the same problem as CWV - although CWV would
> >> > > likely benefit from this.
> >> > >
> >> Yes. But it may define the boundaries within which CWV applies,
> >> assuming that this is kept outside of CWV.
> >> Meaning that if the ssthresh value (relative to CWND) puts the
> > connection in
> >> CA and CWND <= IW, then after a certain idle time, RTO?, the
> >> connection should really not be worse off than a new connection.
> >>
> >> > > Pacing is always going to help in these cases from the network
> >> > > perspective, and probably would be a major performance for apps.
> >> > > If I knew more about Pacing we can certainly write more in the
> >> > > CWV
> > draft.
> >> > >
> >> > > However, I don't think it's a solution on its own - I also think
> >> > > that simply letting cwnd grow without check seems illogical -
> >> > > especially when there are significant changes in available path
> >> > > capacity. That's where I really think CWV is needed.
> >> Agree.
> >> > Absolutely. I completely agree that we need that part of cwv-draft.
> >> > but the second half about reducing cwnd by X after idling Y always
> >> > sounds shamanism. To me there are just two choices.
> >> >
> >> > 1) conservative: revert CC to as in initial slow start (cwnd=RW,
> >> > ssthresh=inf)
> >> > 2) keep cwnd as-is but pace (if available)
> >>
> >> Perhaps the solution shall consist of both of these with
> >> qualification
> > on idle
> >> time on whether the resulting ssthresh and usable CWND from option 2)
> >> puts the connection in a worse position than 1).
> >> >
> >> > the 2nd option follows the same rationale as RFC 2140 on persisting
> >> > cwnd over connections. Yes it might be wrong at times, but the
> >> > immediate threat is burst, not high cwnd. I am not sure about any
> >> > good justification for a third option.
> >> >
> >> > note 1) may still burst if the app writes within an RTO. that
> >> > happens all the time on video transfers when the receiver plays
> >> > abuse receive-window to throttle sender.
> >> >
> >> Yes, and such may happen even at start of a new connection. This
> >> issue
> > is
> >> thus not particular to the situation after idle.
> >>
> >> In SCTP the solution to such  bursting has been to introduce a
> >> max.burst parameter. I think that Randy S. also gave this comment as
> >> the tcpm
> > session
> >> in summer.
> >>
> >> BR, Karen
> >>
> >> > >
> >> > > Gorry
> >> > >
> >> > >
> >> > >
> >> > > On 11/10/2013 18:12, Yuchung Cheng wrote:
> >> > >>
> >> > >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary
> >> > >> <[email-masked]> wrote:
> >> > >>>
> >> > >>> Hi,
> >> > >>>
> >> > >>> I agree with Karen. I have been investigating cases where a
> >> > >>> single packet drop ultimately results in ssthresh getting set
> >> > >>> to 2*MSS and the connection getting severely penalized by
> >> > >>> immediately going into CA at the beginning of a slow-start. One
> >> > >>> case occurs due to a feature intended to limit the severity of
> >> > >>> a DOS attack by a malicious TCP that ignores the receiver's
window
> size (i.e.
> >> > >>> limiting the max number of segments in a reassembly buffer).
> >> > >>> Unfortunately, if the average segment size is small (as can
> >> > >>> happen when data is being compressed on the fly by the sender)
> >> > >>> and the RTT long enough, then a single packet drop in the
> >> > >>> network can be followed by a tail drop at the receiver,
> >> > >>> followed by slow-start with ssthresh = 2*MSS (we are working on
> >> > >>> a solution to avoid this occurrence on perfectly valid
> >> > >>> connections with valid traffic). We are also investigating a
> >> > >>> different case that also results in ssthresh getting set to
> >> > >>> 2*MSS after a
> >> > single packet drop by the network.
> >> > >>>
> >> > >>> The problem is, once ssthresh gets set to a value too far below
> >> > >>> the actual loss flight size, then it can take a very long time
> >> > >>> to recover (and may never recover as long as that connection is
> >> > >>> established). That would be a good thing on real DOS attacks,
> >> > >>> but not so good on valid connections and traffic.
> >> > >>
> >> > >> I have definitely seen this problem (w/ cubic). Although I
> >> > >> believe the root problem is loss is often not correlated with
> >> > >> congestion these days (but due to burst), I second the idea to
> >> > >> reset ssthresh after a long idle. For cubic the hystart will
> >> > >> avoid ss overshoot so it's safer.
> >> > >>
> >> > >> imo newcwv is better than RFC2861 but I prefer to just keep cwnd
> >> > >> as-is and enable pacing. After idle TCP will burst and that's
> >> > >> the real issue. Any cwnd moderation helps to lower burst and
> >> > >> reduce loss, so it might appear the magic factor, be 3/4, 1/2,
> >> > >> 0.1322, is
> > good.
> >> > >> But it's papering the flaw of window-based ack-clocked design.
> >> > >>
> >> > >>>
> >> > >>> I think the problem with ssthresh stems from it being set as a
> >> > >>> function of CWND (which is required to be set to a small value
> >> > >>> in any slow-start situation). I would suggest setting it as a
> >> > >>> function of pipeACK and/or LossFlightSize, which should be
> >> > >>> better indicators of a burst size that can be used without
loss.
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Gary
> >> > >>>
> >> > >>> -----Original Message-----
> >> > >>> From: [email-masked] [mailto:[email-masked]] On
> >> > Behalf
> >> > >>> Of Karen E. Egede Nielsen
> >> > >>> Sent: Friday, October 11, 2013 3:01 AM
> >> > >>> To: [email-masked]
> >> > >>> Cc: [email-masked]
> >> > >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt
> >> > >>>
> >> > >>> Hi,
> >> > >>>
> >> > >>> RFC5681 (section 4.1) stipulates that the TCP should start in
> >> > >>> slow start with IW after an idle period of RTO.
> >> > >>> The associated adjustment of ssthresh, however, has been left
> >> > >>> under-specified. I.e., should the stthresh go to the standard
> >> > >>> restart condition, which then would mean setting ssthresh equal
> >> > >>> to infinite, or should the ssthresh be kept where it was left ?
> >> > >>>
> >> > >>> This question is very significant for a TCP connection where
> >> > >>> the ssthresh is low due to the occurrence of a  prior
> >> > >>> retransmission-
> >> timeout.
> >> > >>> And it is even more  critical if a sequence of 2 retransmission
> >> > >>> time-outs have occurred as the ssthresh then would be left as
> >> > >>> low as 2MTUs (RFC5681)
> >> > >>>
> >> > >>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh
> >> > >>> as ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated
> phase.
> >> > >>> This proposal will result in a severe disadvantage,  compared
> >> > >>> to a clean restart of the connection [ssthresh = infinite],
> >> > >>> when resuming usage after an idle period on a TCP connection
> >> > >>> following a
> >> > retransmission-timeout.
> >> > >>>
> >> > >>> I wonder if there are any thoughts in TCMP, possibly in newcwv,
> >> > >>> possibly in some other work item, on clarifying the ssthresh
> >> > >>> handling when the adjustment ssthresh = max(ssthresh,
> >> > >>> 3*cwnd/4), would bring the connection to start in congestion
> avoidance.
> >> > >>>
> >> > >>> Thanks,
> >> > >>>
> >> > >>> BR, Karen
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> Resume of traffic in a TCP contexts after a (or multiple)
> >> > >>> retransmission-timeout perhaps is a special case for many
> >> > >>> single TCP connection usecase scenarios (I don't know).  At
> >> > >>> least it is clear why one would like to overcome such
> >> > >>> congestion avoidance phase by performing a clean restart.
> >> > >>> But  for SCTP multi-home (read multiple path) scenarios, and
> >> > >>> possibly (?) for MPTCP scenarios as well, then temporary leave
> >> > >>> and subsequent resume of paths where retransmission-timeout
> >> > >>> have occurred is part of the standard failure recovery
> >> > >>> operation of the
> >> > protocol.
> >> > >>> The above issue is thus, apart from it being general relevant
> >> > >>> for TCP I suppose, very relevant for ongoing work in tsvwg on
> >> > >>> CC during path failovers in SCTP (Quick Failover).
> >> > >>>
> >> > >>> -----Original Message-----
> >> > >>> From: [email-masked] [mailto:[email-masked]] On
> >> > Behalf
> >> > >>> Of [email-masked]
> >> > >>> Sent: 10. oktober 2013 05:25
> >> > >>> To: [email-masked]
> >> > >>> Cc: [email-masked]
> >> > >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt
> >> > >>>
> >> > >>>
> >> > >>> A New Internet-Draft is available from the on-line
> >> > >>> Internet-Drafts directories.
> >> > >>>   This draft is a work item of the TCP Maintenance and Minor
> >> > >>> Extensions Working Group of the IETF.
> >> > >>>
> >> > >>>          Title           : Updating TCP to support Rate-Limited
> > Traffic
> >> > >>>          Author(s)       : Godred Fairhurst
> >> > >>>                            Arjuna Sathiaseelan
> >> > >>>                            Raffaello Secchi
> >> > >>>          Filename        : draft-ietf-tcpm-newcwv-03.txt
> >> > >>>          Pages           : 19
> >> > >>>          Date            : 2013-10-09
> >> > >>>
> >> > >>> Abstract:
> >> > >>>     This document proposes an update to RFC 5681 to address
> >> > >>> issues
> >> that
> >> > >>>     arise when TCP is used to support traffic that exhibits
> > periods where
> >> > >>>     the sending rate is limited by the application rather than
the
> >> > >>>     congestion window.  It updates TCP to allow a TCP sender to
> > restart
> >> > >>>     quickly following either an idle or rate-limited interval.
> > This
> >> > >>>     method is expected to benefit applications that send
> > rate-limited
> >> > >>>     traffic using TCP, while also providing an appropriate
> > response if
> >> > >>>     congestion is experienced.
> >> > >>>
> >> > >>>     It also evaluates the Experimental specification of TCP
> > Congestion
> >> > >>>     Window Validation, CWV, defined in RFC 2861, and concludes
> > that
> >> RFC
> >> > >>>     2861 sought to address important issues, but failed to
> >> > >>> deliver
> > a
> >> > >>>     widely used solution.  This document therefore recommends
> >> > >>> that
> >> the
> >> > >>>     status of RFC 2861 is moved from Experimental to Historic,
> >> > >>> and
> > that
> >> > >>>     it is replaced by the current specification.
> >> > >>>
> >> > >>>     NOTE: The standards status of this WG document is under
> >> > >>> review
> > for
> >> > >>>     consideration as either Experimental (EXP) or Proposed
> > Standard
> >> (PS).
> >> > >>>     This decision will be made later as the document is
finalised.
> >> > >>>
> >> > >>>
> >> > >>> The IETF datatracker status page for this draft is:
> >> > >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv
> >> > >>>
> >> > >>> There's also a htmlized version available at:
> >> > >>> http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-03
> >> > >>>
> >> > >>> A diff from the previous version is available at:
> >> > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03
> >> > >>>
> >> > >>>
> >> > >>> Please note that it may take a couple of minutes from the time
> >> > >>> of submission until the htmlized version and diff are available
> >> > >>> at tools.ietf.org.
> >> > >>>
> >> > >>> Internet-Drafts are also available by anonymous FTP at:
> >> > >>> ftp://ftp.ietf.org/internet-drafts/
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> tcpm mailing list
> >> > >>> [email-masked]
> >> > >>> https://www.ietf.org/mailman/listinfo/tcpm
> >> > >>> _______________________________________________
> >> > >>> tcpm mailing list
> >> > >>> [email-masked]
> >> > >>> https://www.ietf.org/mailman/listinfo/tcpm
> >> > >>> _______________________________________________
> >> > >>> tcpm mailing list
> >> > >>> [email-masked]
> >> > >>> https://www.ietf.org/mailman/listinfo/tcpm
> >> > >>
> >> > >>
> >> > >