[tcpm] LimitedTransport||FastRecovery / ABC interaction

["Scheffenegger, Richard" <rs at netapp.com>]

[removed other thread stuff]

Alex,

Again the scenario where the sender is in FastRetransmit or
LimitedTransmit 
mode, following a congestion (drop) event.

Shouldn't a sender, fully honoring RFC 3042, increase the pipe only by
the amount 
of newly ACKed / SACKed octets, rather then increasing the pipe by 1*mss
per
received ACK?

If the sender has a decent cwnd, and a misbehaving (not to say lying)
receiver
all of a sudden sends individual SACKs, ACKing one more octet, and
SACKing
every other octet, each in an individual ACK.

This might lure the sender to bloat it's (retransmission / limited
transmit)
pipe to become much larger than cwnd (I'm not sure if all
implementations
limit the pipe to min(cwnd, pipe)....

But really, I think this is mostly a nit-pick; worst case would be a
burst of
traffic, potentially causing momentarily queue overflows in the network,
and 
(lot's) of retransmissions...

But that later part should be better, when bursty loss can be dealt with
better :)

Regards,

 


Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support 
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com 
Franz-Klein-Gasse 5
1190 Wien 


-----Original Message-----
From: Alexander Zimmermann [mailto:zimmermann at nets.rwth-aachen.de] 
Sent: Montag, 9. November 2009 16:26
To: Scheffenegger, Richard
Cc: tcpm at ietf.org Extensions WG
Subject: Detect Lost Retransmit with SACK

Hi Richard,

firstly welcome on the list :-)
Since your question in not really related to the poll I change the
title...

Comments inline.


Am 09.11.2009 um 13:57 schrieb Scheffenegger, Richard:

>
> One more clarification, which came up after I looked at the FreeBSD  
> implementation of Limited Transmit; this might be a nit-pick, but  
> when RFC 3042 is active, shouldn't ABC also be used during  
> LimitedTransmit / FastRecovery?

Why? One reason for ABC are lying receivers (ACK Division). So, the  
worst case is Slow-Start...

> (FreeBSD MAIN is increasing cwnd by 1 mss for each new ACK, instead  
> for the amount of data in that ack...

What do you describe here? Slow-Start?
RFC 3042 says: "The congestion window (cwnd) MUST NOT be changed when  
these new segments are transmitted."

>
> Thanks a lot!
>
>
> Best regards,

Alex