[e2e] Why do we need TCP flow control (rwnd)?

[Detlef Bosau]

David P. Reed wrote:
> ECN marks share the fate of the packets carrying them.  So what's your 
> point?

O.k., o.k. see

<20080630160711.GC2477 at zod.isi.edu>
<486913EA.5040208 at web.de>

ECN marks cannot fully replace loss as congestion indicator (and they don't, I realized this.

However, I do not see, why ECN marks should replace the use of TCP flow control (what I understand as one of Michael's thoughts,
<20080627080835.GA14740 at ikr.uni-stuttgart.de>).
Particularly because ECN marks can get lost. Wrt. CC, this is no problem because the packet loss is a congestion indicator itself.
Particularly, a lost packet does not clock out anything from the sender.

In contrast to that, an ACK packet with vaid rwnd will inform the sender correctly about the available receiver capacity.

Executive summary: TCP flow control works fine, we should leave it alone.





>
> Detlef Bosau wrote:
>> Michael Scharf wrote:
>>> Instead of dropping arriving packets or not sending acks, the receiver
>>> could also send an ack with ECN marking (assuming ECN usage is
>>> negotiated).
>>
>>
>> ECN marks can get lost.
>>
>> In addition: How many data may follow the first dropped packet?
>>
>> When the receiver is fed up, why shouldn't he simply tell the sender 
>> instead of seeing it waste network capacity for useless retransmits?
>> And rwnd is _not_ lost - because it is part of any acknowledgement. 
>> When rwnd is lost, the whole ACK is lost, this causing the sender to 
>> stop.
>>
>>>  This would also throttle the sender, but not require a
>>> retransmission. To my understanding, ECN marking would not cause all
>>> these problems.
>>>   
>>
>> As I said: What makes "ICN" (implicit congestion notificatin, i.e. by 
>> missing ACK) preferable over "ECN" is: Loss cannot get lost.
>>
>>> Thus, a receiver running out of buffer space could just use ECN
>>> instead of shrinking rwnd. 
>> And what is the propper reaction at the sender's side? rwnd my be 
>> shrunk only temporarily for some reason.
>> So, this may perhaps not even throttle the sender.
>> ECN causes at least one congestion recovery action per "round", IIRC.
>>
>>
>>
>>


-- 
Detlef Bosau                          Mail:  detlef.bosau at web.de
Galileistrasse 30                     Web:   http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937