Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 1 Apr 2011 08:59:08 +0100

Hi nandita,

I understand the "global" bound. In a (hypothetical) scenario where the sender becomes app limited during the prr-rb phase, the socket may become empty shortly. When the app continues, the sender may clock out a larger burst. 

Iirc, linux has another clamp at no more than 3 seg/ack during loss recovery...

Imho such a secondary clamp makes sense to alleviate bursts after app stalls

That's the background of my question

Richard

________________________________

Von: Nandita Dukkipati <[email-masked]> 
An: Scheffenegger, Richard 
Cc: Michael Welzl <[email-masked]>; [email-masked] <[email-masked]>; SCHARF, Michael <[email-masked]> 
Gesendet: Fri Apr 01 05:57:48 2011
Betreff: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? 

	I would also be interested in learning how the algorithm behaves, when more then one half of the window is lost (ie, there aren’t enough ACKs sent back to clock out each allowed data segment by it’s own ACK). Will it clock out multiple segments per ACK (and if so, will they be spread over the remaining ACKs, so to limit the maximum number of sent packets per ACK – or would PRR-RB by itself allow a burst of packets being clocked out by a single ACK? 

PRR-RB can clock out multiple segments per ACK but has a bound - on every ACK the cumulative amount of data sent in recovery is bound by the amount of data delivered to the receiver during recovery. This is unlike in rfc3517, where larger the losses are, the bigger the burst can be (upto [ssthresh - pipe]). Will send out an example with this scenario after I get back to Cal.

	I think Linux does such a send-rate clamping automatically – how is the interaction with PRR-RB, should that not be part of this draft too)?

Linux does the clamping by reducing cwnd to min(ssthresh, pipe + 1) on each ACK in recovery. This has the unfortunate behavior in that: 1) it is limited to clocking out at most 1 packet/ACK, and 2) for short Web traffic or when the application is temporarily running out of new data to send, pipe reduces to 0, so cwnd == 1 at the end of recovery. PRR-RB will replace the above and so no question of interaction. 

	From: Nandita Dukkipati [mailto:[email-masked]] 
	Sent: Donnerstag, 31. März 2011 03:30
	To: Michael Welzl
	Cc: [email-masked]; SCHARF, Michael
	Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?

	On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl <[email-masked]> wrote:

	i am in principle interested and have the impression that this is probably a useful document, but too complicated. maybe an example would help?

	That's a great idea - we will post a couple of examples within next few days on how the algorithm behaves under single and multiple losses. It is actually surprisingly simple.

		On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote:

		Folks,
		
		since we ran out of time during the TCPM session, I shifted the
		discussion of draft-mathis-tcp-ratehalving-00 to the list.
		
		In order to trigger this discussion, I'd like to start an informal poll
		who would in principle be interested in the topic of that draft. If so,
		please reply to this email. Of course, any technical comment would be
		excellent.
		
		Thanks!
		
		Michael
		_______________________________________________
		tcpm mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/tcpm

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