So I get the idea in most cases, you keep a low resolution texture for an object that is say 500 feet away, then maybe at 100 feet you load in a better version, but I don't get what the streaming is. I fully understand something like clip mapping, but I'm trying to keep chunks of my terrain far away from using the high detail texture and just use the lowest texture size it needs.

1024 texture
1.) 500 feet away, just load Mip-Map from 1x1 up to 32x32
2.) 100 feet away, Load the full 1024 texture

So on step 2 do I delete the old texture and upload the 1024 texture (even the 1x1 to 32x32), or am I simply forcing an LOD bias at 500 feet so that only the 32x32 and lower are ever actually bound?

I was looking to improve some terrain and saw this (search for "A quadrant mask texture is then created in paint software") and you will see what specific streaming I am looking to do. Basically terrain that has a bunch of chunks with huge textures. So I'm wondering what I stream and where I stream it to.
Terrain Texturing

Maybe I create a 1024 image in my example but only send glTexImage2D to the levels 1x1 to 32x32 and then fill in the other data later? (This just doesn't make sense because I would be wasted memory I'm not using).

Or do I reserve slots where low res images can come and go that I never delete, I just overwrite, and then later when going to the high res I mark that slot as allowed to overwrite with a new low res texture?

"What is texture streaming" depends on the game/engine's needs
e.g. if the engine is using SVT/megatextures, then it might also be using custom/limited mipping, and be able to manually choose how it lays out mips in VRAM.

In the perfect case, streaming would let you only ever have in memory the mip-maps that are actually used each frame (not too low and not too high).

Modern hardware has sampler states that let you specify the minimum and maximum mip level that can be sampled, which allows you to upload an incomplete mip-chain while still guaranteeing that only the valid levels will be used.

Depending on the graphics API that you're using, you may be able to allocate incomplete mip chains without wasting VRAM. I'm not up-to-date with my OpenGL knowledge, so I can't answer that specifically.
Alternatively, yeah you could use a resource pooling system, where for example, you could have half a dozen 1024 textures and a few dozen 256 textures. When moving to new parts of the map, you could move some of the 1024's into the 256 slots (chucking out the top 2 mips in the process), and move some of the 256's into the 1024 slots (and limiting their valid mip levels), then start a background process to load the missing 2 mip levels.

In the perfect case, streaming would let you only ever have in memory the mip-maps that are actually used each frame (not too low and not too high).

Modern hardware has sampler states that let you specify the minimum and maximum mip level that can be sampled,[/quote]

Well for my example, say my terrain strecthes like 16000x16000 pixels. I cut it up into 2048 chunks. If I force all the chunks that I'm not standing on to be say mip-map 32x32 or smaller, then does this guarantee the mips up to 2048 will be cached as to not keep all my memory used up? Or is this something I have to manually do.

which allows you to upload an incomplete mip-chain while still guaranteeing that only the valid levels will be used.[/quote]
But does it not already reserve my texture memory even if I only upload say 2x2 mip map of my 1024 texture or no? Even so, what happens when I drop in the 1024 (level 0) mip map when I am on top of that terrain, then I fly past it and want to go back to my lower mip maps. I cant just delete 1 mip-map chain to free up just the 1024 space. The only thing I can do is force the LOD mip map to be smaller resolution.

Lets just say I went nuts and said I want 32x32 chunks. When I am standing on any one chunk I want them to hold 2048 texture. So I have 32x32 2048 textures and I need to manage which chunks can only hold certain resolution images. It seems relying on the GPU to manage memory just by controlling Mip-Map LOD is not actually freeing up any memory at all. So it seems as if it will hold 32x32x2048 worth of memory. The only solution that I think would work is making buckets and at some point I walk and I say ok this one needs a 2048 that I'm on and the last one I was on should go down a step to 1024. So instead of deleting and making new textures I just re-upload pixel data and make the chunks swap textures 2048 to 1024 and 1024 to 2048.

I guess maybe I'm trying to much as a 2048 RGB DDS image is only 2MB of memory so I can store a ton of them and just worry about performance instead and switch the mip-map bias in case performance drops.

Yea I got how streaming PBO's skip the cpu and just work with the driver. In the article I posted they said they would stream 4, 4096 textures and I was trying to understand how they are implementing it and what they are streaming. They are probably using PBO's but its like, well what are they actually streaming in and streaming out.