Re: [tcpm] RFC3465:TCP ABC and SACK'ed data

["Zimmermann, Alexander" <Alexander.Zimmermann at netapp.com>]

Hi,

Am 21.05.2014 um 09:36 schrieb Erik Hugne <erik.hugne at ericsson.com>:

> TCP ABC (still in the experimental track) defines a method to increase the cwnd
> based on the bytes being acknowledged, instead of the number of acks that
> arrive. I am assuming that SACK'ed (RFC2018) data should be included in this
> calculation, but i could find no mention of this in RFC3465.
> Could someone confirm this?

No, SACKed data is not included. RFC 5681 says that you increment the CWND for
each ACK received that *cumulatively* acknowledges new data. The same applies
for ABC.

SACKed data „counts“ as DUPACKs. C&P from RFC 6675: „For the purposes of this
specification, we define a „duplicate acknowledgment“ as a segment that arrives
carrying a SACK block that identifies previously unacknowledged and un-SACKed
octets… „

> 
> What i'd like to achieve with this is to solve an issue that follows after a
> TCP path change where a large portion of the window have been lost. On the
> new path, the data that was successfully passed to the receiver is sacked
> and the rest is being retransmitted. This prevents the cwnd from growing and the
> throughput is very low.

Why? For each received SACK block you will later get a cumulative ACK (as soon as
the retransmission arrives) which includes the SACK block and which increases the
CWND. In other words: as soon as a full ACK arrives (an ACK which covers the
RecoveryPoint), the CWND will increased on the basis of all newly cumulatively
acknowledged data (if ABC is on)

Alex


> 
> Am i correct in that a SACK-aware ABC implementation would allow the cwnd
> to grow and the "hole in the window" to be closed faster?
> 
> //E
> 
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail