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

From: [email-masked]
Date: Wed, 09 Oct 2013 20:25:07 -0700

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/

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Fri, 11 Oct 2013 12:01:29 +0200

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.

Abstract:

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.

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "McAlpine, Gary" <[email-masked]>
Date: Fri, 11 Oct 2013 16:50:50 +0000

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

Abstract:

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.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 11 Oct 2013 17:08:15 +0000

I see another effect.
The flightsize that caused the packet drop is much larger than
the flightsize at the time the drop is detected.

Suppose we send 42 segments.
The last 6 got dropped.
Peer sends back acks for the first 36 of them,
each one with a reduced advertised window, because the
peer app has not read the socket buffer.
This does not allow us to send more data, because
the right edge of the window does not advance.
Soon, the peer app reads the socket buffer, so the
peer starts sending window updates to advance the
right edge of the window.
Now, we send more data and the peer sends back dup
acks to indicate the dropped packets.
The problem is that the flightsize is now very small.
Setting the new cwnd to 1/2 of that is senseless.
The problem flightsize was the original 42.
What we really should set the new cwnd to is a little
less than 36, because 36 segments made it.

Thanks,
Jakob.

> McAlpine, Gary
> Sent: Friday, October 11, 2013 9:51 AM
> To: Karen E. E. Nielsen; [email-masked]
> Cc: [email-masked]
> 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 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
> 
> Karen E. Egede Nielsen
> 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.
> 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
> 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.
> suppose, very relevant for ongoing work in tsvwg on CC during path failovers
> in SCTP (Quick Failover).
>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 11 Oct 2013 10:12:41 -0700

> 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 establ…
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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 11 Oct 2013 18:50:53 +0100

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.

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.

Gorry

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 12 Oct 2013 09:20:17 -0700

On Fri, Oct 11, 2013 at 10:50 AM, Gorry Fairhurst <[email-masked]> wrote:
>
> 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.
>
> 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.
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)

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.

>>> 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 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
>>> LossFlightSize, which should be better indicators of a burst size that can
>>> be used without loss.
>>>
>>> Thanks,
>>> Gary
>>>
>>> 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 ?
>>>
>>> restart of the connection [ssthresh = infinite],  when resuming usage after
>>> an idle period on a TCP connection following a retransmission-timeout.
>>>
>>> adjustment ssthresh = max(ssthresh, 3*cwnd/4), would bring the connection to
>>> start in congestion avoidance.
>>>
>>> Thanks,
>>>
>>> BR, Karen
>>>
>>>
>>>
>>> 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.
>>> for MPTCP scenarios as well, then temporary leave and subsequent resume of

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 14 Oct 2013 11:10:14 +0200

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.
> >
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.

> > 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.
> but the second half about reducing cwnd by X after idling Y always
sounds
> shamanism. To me there are just two choices.
>

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.
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

> >>> 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.
> >>>
> >>> 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
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of Karen E. Egede Nielsen
> >>> RFC5681 (section 4.1) stipulates that the TCP should start in slow
> >>> start with IW after an idle period of RTO.
> >>> 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
> >>>
> >>>
> >>>
> >>> 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).
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of [email-masked]

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 15 Oct 2013 10:50:23 -0400

> gave this comment as the tcpm session in summer.

Thanks for the reminder, there is indeed a third option and is widely
implemented in BSD, according to Randy. max-burst is a middle-road between
cwnd/pacing and iw/ss. but what if the app sends max.burst bytes per-write
frequently enough to form a big burst? it seems possible with TSO
(deferral). So I guess the implementation has some kind of rate-limiting,
similar to pacing, to deal with that.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 Oct 2013 19:14:31 +0100

This all helps, to figure how much still needs to be done, please see 
comments in-line.

Gorry

>> off than a new connection.
GF: I'm intrigued in the idea of "resetting" ssthresh when there is no 
negative information for a long enough time to know that the network is 
again stable, this would be a big change to TCP. I don't think RTO is 
enough time, i.e. we would need to use a much longer time since the last 
loss event than simply an RTO.

There is a possibility also that if the loss occurs in a shared 
bottleneck that you may lead to synchonisation and instability at some 
predictable time after you increase the ssthresh. Increasing ssthresh 
may not be easy.

>>> burst, not high cwnd. I am not sure about any good justification for a
GF: I'll "revive" the thinking behind new-cwv:

The primary goal of new-cwv is to stop cwnd growing arbitrarily when the 
application rate is reached, and to allow it to be kept at this "safe" 
rate for future use.

The issue though, which is where the "decay" comes in, is when an app 
does not use a reasonable fraction of the capacity associated with cwvnd 
for a *long* time (NVP), and then starts to resume at what TCP then 
perceives as the "safe" rate. [This is more to deal with issues such as 
path changes, apps being idle for long period and then simultaneous 
waking-up on some trigger, re-routes, etc.] I think these are all corner 
cases, but we need to robust.

So... We currently take this decision of using a NVP period of 5 minutes 
to cover this corner case.

If the WG now decides to reset ssthresh high after a period of time, 
this would affect the choice of the NVP period and the final value of 
ssthresh. We should ask people how comfortable they would be in this 
change.

> similar to pacing, to deal with that.
Max-burst maybe what we seek in terms of trying to restore pacing for an 
ACK stream - and is a really valubale method - I think the reported 
experience with SCTP is all positive, and it is easier to implement than 
pacing.

However, one of the features of the apps governed by new-cwv is that in 
many cases there is no ACK clock - therefore max-burst could not be used 
when an APP transmits in bursts and goes idle in between. This varying 
application behaviour is why we have proposed the methods in the draft, 
and why some form of pacing may be very desirable (or at least reassure 
sceptics that the new methods really are safe).

I'm still hoping someone will tell us that you can turn-on pacing for 
times when TCP would benefit - and if so, we should make transmission 
during the NVP to be paced.