Subject: RE: [Tsvwg] SCTP Max.burst and CWND

From: [email-masked]
Date: Fri, 1 Mar 2002 18:55:48 +0200

Hi Rainer!

	See some comments inline...

> Hello!
> 
> For those short in time first the summary of my mail.
> 
> Summary: The task of preventing bursts which cause congestion 
> is addressed
> by CWND,
> but the rules are incomplete at the time.
> Rules for decrease of CWND when it is partly used are 
> missing. This would
> also prevent 
> bursts causing congestion in situations when no fast 
> retransmit takes place.
> 
> A workaround of the problem is Max.Burst, but it must be 
> always applied, not
> only after
> fast retransmission.
> 
> 
> Concerning the 'Max.Burst' handling the current SCTP Imp. Guide 
> is not very specific.
> 
>    Upon acknowledgment of a DATA chunk that has been fast 
> retransmitted,
>    the protocol parameter 'Max.Burst' MUST be applied to 
> limit how many
>    SCTP packets may be sent upon the completion of SACK processing.
> 
> Does this limit the application of Max.Burst only to the first send 
> triggered by the first SACK after a FR, or has it a longer effect?

	Well, the idea is that you want to avoid that specific SACK to trigger the sending of more than Max.Burst packets. You should send at most that number of packets (full MTUs) and wait for the reception of another SACK... Maybe, if the cwnd was so high, the next SACK would trigger more than Max.Burst packets, but, unless that second SACK also acknowledges a previously FR chunk, you don't apply the limit...

> IMHO if we introduce Max.Burst because we think bursts are dangerous 
> then we should always apply this limit to any response on a SACK,
> independent from 
> the 'history'.
> The solution description mentions that clamping RWND to 0 
> over a period of
> time is the 
> cause for bursts, and I think this may happen most likely but 
> not only in
> combination 
> with FR.
> 
> Let me describe also a more elegant solution to prevent the 
> negative effects
> of bursts without the Max.Burst method.
> Please correct me if I'm wrong.
> The problem is not the burst itself, but the burst after some 
> time of very
> low traffic, e.g 
> zero window probing.

	Well, the burst itself is also a problem...

> A second flow sharing bandwith of a limited bandwith link can 
> increase its
> CWND while we 
> are zero window probing, but our CWND stays the same. 
> After release of the RWND=0 condition we use our full CWND 
> which causes
> congestion
> and losses on the link. So the real problem is, that our CWND 
> doesnt decay
> when we use 
> only a part of it.
> If we cut our CWND in half once per RTT as we do when idle 
> would solve the
> problem, 
> because we shrink our CWND faster than other flows would 
> increase their
> CWND, and so 
> we can use our full CWND any time without exeeding the total 
> link capacity.

	You have to half your cwnd if it stays idle during one RTO... But halving it every RTT is far too restrictive in my opinion...

> Another improvement is to define a general rule to decrease 
> CWND when it is
> not fully 
> used, i. e. flightsize is smaller than CWND.
> I could think of something like NEW_CWND=CWND-0.5*(CWND-flightsize).

	But then, you would hardly increase your cwnd... When you are just few milliseconds waiting, you will shrink the cwnd... I should think a little bit more about this, but I don't think it is a good idea... :-/

> Imagine the situation of two flows A,B sharing a link equally 
> (50%) . Now A
> reduces 
> throuput to 10%, B can increase to 90%.
> When A swithes back to 50% we have a massive burst and 
> overload, and without
> FR 
> involved.
> With CWND reduction mechanism A cannot switch back 
> immedeately to 50% but

	Well... if it has been idle for a long time, it will decrease its cwnd... I think that problem here is to define what is the meaning of "long time"... :->

> increases 
> with less congestion in the network. 
> 
> It would be interesting if someone could simulate these 
> suggestions, or if
> there are any 
> papers dealing with CWND decrease? 

	I don't really know...

	BR Iván Arias Rodríguez

> Best regards
> 
> Rainer Benedict
> 
> 
> -- 
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: "Rainer" <[email-masked]>
Date: Sat, 2 Mar 2002 11:56:08 +0100

Hi Ivan!

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 01, 2002 5:55 PM
Subject: RE: [Tsvwg] SCTP Max.burst and CWND

Hi Rainer!

> triggered by the first SACK after a FR, or has it a longer effect?

Well, the idea is that you want to avoid that specific SACK to trigger the
sending of more than Max.Burst packets. You should send at most that number
of packets (full MTUs) and wait for the reception of another SACK... Maybe,
if the cwnd was so high, the next SACK would trigger more than Max.Burst
packets, but, unless that second SACK also acknowledges a previously FR
chunk, you don't apply the limit...

[RB]
I  wanted to point out
- that the current wording in the imp guide makes not clear (at least for
me) how often you apply the limit,
- that it would be a good idea to limit bursts always, independent of their
reason.
By the way, is there a similar burst limit for TCP?

[RB]
IMHO A burst is only a problem if the sum of all flows exceeds the total
link bandwith, and routers have to drop packets. If we are not sending for
only a very short time (say one RTT) the other flows wont increase their
bandwith very much and we can send a burst of the size of the full CWND,
without producing overload. If we dont send for a longer peroid, other flows
increase, and we should not send bursts with ths size of CWND, because our
CWND doesnt show the actual situation on the link. Therefore my idea to
schrink it, if it is not fully used, so that it shows the actual situation
on the link again.
I must confess that this idea is idealized and MAY be a disatvantage when
competing with TCP.

> we can use our full CWND any time without exeeding the total

You have to half your cwnd if it stays idle during one RTO... But halving it
every RTT is far too restrictive in my opinion...

[RB]
But we half it EVERY RTO when we are idle, and RTT and RTO are of the same
order of magnitude, so I dont see a big difference.

> I could think of something like NEW_CWND=CWND-0.5*(CWND-flightsize).

But then, you would hardly increase your cwnd... When you are just few
milliseconds waiting, you will shrink the cwnd... I should think a little
bit more about this, but I don't think it is a good idea... :-/

[RB]
I would only shrink it when flightsize is smaler than CWND, i.e. when I dont
need it. If it is fully used it grows according to the normal congestion
control rules. I think you are right, there may be a disadvantage compared
with TCP when payload is very bursty, maybe simulations can show.

> With CWND reduction mechanism A cannot switch back

Well... if it has been idle for a long time, it will decrease its cwnd... I
think that problem here is to define what is the meaning of "long time"...
:->

I don't really know...

BR Iván Arias Rodríguez

 Best regards

 Rainer Benedict

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Sat, 2 Mar 2002 14:22:34 -0500 (EST)

> By the way, is there a similar burst limit for TCP?

I remember reading a paper co-authored by Sally Floyd (can't remember
title) which simulated performance of SackTCP. That paper introduced the
idea of using Max.Burst. I remember there were some slight differences in
the way that paper recommended its usage, but it is all fairly vague in my
mind now.

> schrink it, if it is not fully used, so that it shows the actual situation

Yes, this is what I was arguing too.

> I must confess that this idea is idealized and MAY be a disatvantage when

Agreed.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0