Re: Successful remote AES key extraction

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 04/22/05 

Date: Fri, 22 Apr 2005 14:50:09 -0600

"D. J. Bernstein" <djb@cr.yp.to> writes:
> That's a crazy premise. Network load simply doesn't work that way in the
> real world. Packets come in waves and bursts and spikes, forcing almost
> all hops to have far more capacity than they usually need.

this is one of the issues raised with the original slow start stuff
... some of the prototyping had been done on direct ethernet
connection between two hosts.

I believe that the same month that slow-start presentation was made an
an IETF meeting ... there was a paper published in ACM SIGCOMM
proceedings about slow-start not being stable in real-world
environments (because of things like significant bursty trends).

for a little side drift ... one of the issues has been communication
protocols using windowing algorithms to coordinate the number of
outstanding sent packets with the amount of buffers at receiving nodes
(originally in direct point to point links involving latency either in
transmission and/or at end-point processing).

Windowing tends to only be indirectly related to amount of
intermediate node congestion. Intermediate node congestion tends to be
things like the arrival rate and stuff like back-to-back packet
arrivals. One of the issues raised in the early SIGCOMM proceedings
paper is that returning ACK-packets (which open windows) can get
bunched up ... which results in opening multiple windows at the
sending side. The sending side then tends to transmit multiple
back-to-back packets (for the size represented by the multiple bunched
ACKs). The multiple back-to-back transmission by the sender then tends
to aggrevate saturation and congestion at intermediate nodes (this
bursty characteristic is one of the things contributing to non-stable
slow-start operation).

If the multiple arriving back to back packets contribute to
intermediate node saturation ... a possible solution is to have
time-delays between packet transmission to address intermediate node
congestion. However, it is possible to create an infrastructure that
dynamically adjusts the intermediate transmission delay to address
intermediate node saturation ... and totally ignore window-based
strategies.

for HSDT in the mid-80s, we had done rate-based pacing w/o having to
resort to windowing oriented algorithms for long latency network
connections. a problem at the time of slow-start work was that there
were a whole class of machines and software with primitive timing
faclities that made if difficult to implement rate-based pacing using
a dynamically adaptive inter-packet transmission delay (directly
controlling the rate of packet production in order to influence the
rate of packet arrival at intermediate nodes).

misc. hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/