Re: [tcpm] rfc2581bis-01 and RFC 2861

There are a lot of disparate things in your email.  Let's see ...

> True. I guess the question is when/if RFC 2861 will be incorporated as
> a Standards track rfc. As you are probably aware, Linux 2.4 and
> onwards implement 2861. Ofcourse, this is not the reason for making an
> experimental RFC a standard but I was hoping to find some effort
> towards it. Perhaps, there is one but I have not scanned all the
> archives. Also, such an effort is not evident from the WG description
> and 'Goals and Milestones'.

With my WG chair hat on .... This WG certainly can be a forum for
advancing specs (e.g., from Experimental to PS).  That general notion is
in the charter and if someone wanted to bring forth the energy to
consider the advancing of RFC2861 I think that'd be fine for the WG to
consider.  Enough with the hat.

> So I guess, there are two ways of increasing cwnd during CA. One is to
> increase the window based on number of ACKs received (which is what
> Linux is doing and eq (2) in RFC 2581) and the other is to increase it
> based on number of bytes ACKed (2581: page 5, par 3). It appears that
> RFC 2581 recommends both. As you mentioned, the new draft recommends
> the later.

The draft (and RFC 2581) *allows* both and the draft *recommends* byte
counting during CA.

> Now consider CBR over TCP. The window will increase quickly for the
> first case assuming packets are smaller than MSS (100 byte packet and
> 1448 byte MSS). It will increase slowly for the second case. For a MSS
> of 200 bytes and packet size of 100 bytes, the cwnd increase rate is
> 1/2 of the first case.

Yes.  One could argue that the faster increase (the traditional
approach) is inappropriate, but it is a pretty small effect (and, it can
cut both ways---sometimes being beneficial and sometimes not).

> When there is a TDACK loss, cwnd will be reduced to half. The CBR over
> TCP traffic is not impacted if after a loss cwnd is big enough to
> maintain the rate.

RFC 2581 bases the reduction of cwnd on FlightSize (amount of
outstanding data) not cwnd.  So, the CBR over TCP will be reduced by
half.  I.e., if you have 10 packets outstanding, a cwnd of 100000
packets and take a loss your new cwnd should be 5 packets.  The notion
of FlightSize was introduced into the spec. to accommodate cases whereby
the cwnd does not accurately reflect the load being placed on the path.
(As has been discussed on this list before, this is not an ideal fix
because it causes issues in another case.)

allman