[ih] internet-history Digest, Vol 84, Issue 4

[Detlef Bosau]

Am 21.05.2014 21:08, schrieb Noel Chiappa:


> And as to what to do when a timeout happened (which usually, although not
> always, indicates that a packet has been dropped due to congestion), it says:
>
>   if the retransmission timeout expires on a segment in the retransmission
>   queue, send the segment at the front of the retransmission queue again
>   [and] reinitialize the retransmission timer

thanks a lot, I should read texts much more carefully.
> That's it! Again, note the focus on 'hey, we gotta get the user's data there
> as fast as we can'.

However, at a first glance (I will implement this) this appears as a
"quasi GBN".

Do I understand this correctly: When the packet is retransmitted, a copy
is _appended_ to the retransmission queue?
>
> Absolutely no thought given to 'hey, maybe that packet was lost through
> congestion, maybe I ought to consider that, and if so, how to respond'. The
> later 'if you have a congesitve loss, back off exponentially to prevent
> congestive overload' stuff is completely missing (and would be for some time,
> probably until Van, I would guess).
>
> I fairly vividly remember being the IETF where Van gave his first talk about
> his congestion work, and when he started talking about how a lost packet was
> a congestion signal, I think we all went 'wow, that's so obvious - how come
> we never thought of that'!
>
> The TCP RFC does, however, spend a great deal of time talking about the window
> (which is purely a destination host buffering thing at that point).
>
>
> Looking at RFC-792 (ICMP) there's a fair chunk in the Source Quench
> section about congestion, but little in the way of a solid algorithmic
> suggestion:
>
>   the source host should cut back the rate at which it is sending traffic to
>   the specified destination until it no longer receives source quench
>   messages from the gateway
>
> (And I still think SQ has gotten a bad rap about being ineffective and/or
> making things worse; I would love to see some rigorous investigation of
> SQ. But I digress...)
>
>
> The 'Dave Clark 5' RFCs are similarly thin on congestion-related content:
> RFC-813, "Window and Acknowledgement Strategy in TCP" (which one would assume
> would be the place to find it) doesn't even contain the word 'congestion'!
> It's all about host buffering, etc. (Indeed, it suggests delayed ACKs,
> which interrupts the flow of ACKs which are an important signal in VJCC.)
> And one also finds this gem:
>
>   the disadvantage of burstiness is that it may cause buffers to overflow,
>   either in the eventual recipient .. or in an intermediate gateway, a
>   problem ignored in this paper.
>
> It's interesting to see what _is_ covered in the DC5 set, and similar
> writings: Dave goes into Silly Window Syndome at some length, but there's
> nothing about congestive losses.
>
> Lixia's "Why TCP Timers Don't Work Well" paper is, I think, a valuable
> snap-shot of thinking about related topics pre-Van; it too doesn't have much
> about congestive losses, mentioning them only briefly. The general sense one
> gets from reading it is that 'the increased measured RTT caused by congestive
> losses will cause people to back off enough to get rid of the congestion'
> (which wasn't true, of course).
>
> I haven't read Nagle's thing, but that would also be interesting to look at,
> to see how much we understood at that point.
>
>
> So I think congestion control was so lacking, in part, because we just hadn't
> run into it as a serious problem. Yes, we knew that _in theory_ congestion
> was possible, and we'd added some stuff for it (SQ), but we just hadn't seen
> it a lot - and we probably hadn't seen how _bad_ it could get back then.
>
> (Although experience at MIT with Sorcerer's Apprentice had shown us how bad
> congestive collapse _could_ get - and I seem to recall hearing that PARC had
> seen a similar thing. But I suspect the particular circumstances of SAS, with
> the exponential increases in volume, even though it was - in theory! - a
> 'single packet outstanding' protocol, might have led us to believe that it
> was a pathological case, one that didn't have any larger lessons.)
>
> We were off fixing other alligators (SWS, etc) that actually had bitten us
> at that point...
>
> So I suspect it was only when congestive collapse hit on the ARPANET section
> of the Internet (shortly before Van's work) that it really got a focus.
>
> 	Noel


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de