Subject: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00?

From: "SCHARF, Michael" <[email-masked]>
Date: Wed, 30 Mar 2011 23:21:56 +0200

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 31 Mar 2011 01:43:30 +0200

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

but i am also a bit drunk  :-)

cheers
michael

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

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

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 31 Mar 2011 00:08:59 +0000

I would be interested, I think this is a very useful addition to 3517. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Wednesday, March 30, 2011 4:44 PM
To: SCHARF, Michael
Cc: [email-masked]
Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00?

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

cheers
michael

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

> 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

---

From: Nandita Dukkipati <[email-masked]>
Date: Thu, 31 Mar 2011 03:24:42 +0200

Hi everyone,

For those not present at the meeting, here's the link to the presentation
slides. We welcome any questions or suggestions.
link: http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf

thanks,
-Nandita

---

From: Nandita Dukkipati <[email-masked]>
Date: Thu, 31 Mar 2011 03:30:14 +0200

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.

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 31 Mar 2011 12:25:44 +0300 (EEST)

> discussion of draft-mathis-tcp-ratehalving-00 to the list.

...I assume the draft name in the subject is actually what you meant 
(the one given here is a bit prehistoric already ;-))...

> please reply to this email. Of course, any technical comment would be

I find the idea itself useful and quite intuitive (but I didn't have time 
just yet to actually convince myself about the details of the given 
algorithm). ...I've never liked too much about the dubious approach of 
RFC2581/5681 where TCP pauses first and then continues with exactly the 
same rate as it did before the congestion was detected.

-- 
 i.

---

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 31 Mar 2011 12:19:04 +0200

> ...I assume the draft name in the subject is actually what 
> you meant (the one given here is a bit prehistoric already ;-))...

Of course, I meant draft-mathis-tcpm-proportional-rate-reduction-00.

Sorry, this was a copy and past error; I had both drafts open in
parallel in the Web browser. Thanks for pointing this out!

Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 12:26:39 +0100

Are you asking about the ratehalving or the proportional rate reduction draft?

I like the general idea, but matt pointed out that ratehalving has serious issues when the data socket runs empty and the sender is application limited; with the proportional rate reduction, this aspect is fixed (which I consider very important for my use case), thus I'm in full support of the PRR-RB draft.

(Afaik, it also fixes the half-way RH implementation of Linux, another good aspect).

Richard Scheffenegger

> From: SCHARF, Michael [mailto:[email-masked]]
> Sent: Mittwoch, 30. März 2011 23:22
> To: [email-masked]
> Subject: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-
> reduction-00?
> 
> Folks,
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 12:26:40 +0100

Murari,

PRR-RD is not limited to the SACK case though (but it works near optimal when SACK is enabled) :).

Are you saying you'd want to use it only together with SACK, retaining NewReno for non-SACK sessions?

Richard Scheffenegger

> From: Murari Sridharan [mailto:[email-masked]]
> Sent: Donnerstag, 31. März 2011 02:09
> To: Michael Welzl; SCHARF, Michael
> Cc: [email-masked]
> Subject: Re: [tcpm] Interestin draft-mathis-tcpm-proportional-rate-
> reduction-00?
> 
> probably a useful document, but too complicated. maybe an example would
> help?
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 12:26:40 +0100

> From: Ilpo Järvinen [mailto:[email-masked]]
>
> I've never liked too much about the dubious approach of

Fully agree - the current behavior actually causes subsequent losses, particular in low-latency environments (where the RTT is in the same order of time, as the network conditions change. with the current standard response, there is a high likelihood that your retransmissions hit the network -with the same rate as noted - while the congested condition still persists. This subsequently often (well, with easily observable probability) leads to lost retransmissions and then to a retransmit timeout to recover from that... (unless you sway from RFC3517 like Linux does)

The immediate reduction in sending rate is a very very useful property. The numbers shown in the presentation seem to support my claim above (fewer retransmission timeouts with PRR-RB at comparable fast retransmit events). This even though Linux can already recover many lost retransmissions with SACK though!

Richard Scheffenegger

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 12:26:40 +0100

Nandita,

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

Richard Scheffenegger

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?

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.

	Folks,

	
	Thanks!
	
	Michael

---

From: Matt Mathis <[email-masked]>
Date: Thu, 31 Mar 2011 23:06:10 -0400

When you said "interest", did you actually mean as a WG item?   You
didn't quite ask the question.

We plan to update the document and bring it to the next IETF in any
case, and we know of  a number of individuals who have expressed
interest.

My only reservation with making it a WG item is that we expect to
broaden the scope somewhat, and the current file and document names
may not be appropriate.   As long as a future scope changes are not a
problem, a WG item would be preferred.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Thu, Mar 31, 2011 at 7:26 AM, Scheffenegger, Richard <[email-masked]> wrote:
> Nandita,
>
>
>
> 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?
> 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)?
>
>
>
>
>
> Richard Scheffenegger
>
>
>
> Subject: Re: [tcpm] Interest
> indraft-mathis-tcpm-proportional-rate-reduction-00?
>
>
>
> i am in principle interested and have the impression that this is probably a
> useful document, but too complicated. maybe an example would help?
>
>
>

---

From: Nandita Dukkipati <[email-masked]>
Date: Fri, 1 Apr 2011 06:57:48 +0200

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

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