[e2e] congestion control for flows w. small packets

[Joerg Widmer]

> > TCP throughput scales linearly with the packet size (half the packet
> > size results in half the throughput).
> 
> Sorry, no. half the _segment_ size results in half the throughput for
> the same rate of generated segments, although that doesn't necessarily
> hold for errors or congestion
True. I tried to keep it short and (a bit too) simple.

> okay, so we're on the edge in this discussion.
I guess that's where the bottleneck is likely to be.

> using even more of the link capacity for headers and increasing the
> chances of a drop along the path triggering congestion avoidance, if
> your flow is congestion-sensitive?
It's easy to account for the 40 bytes overhead when sending smaller
packets. So the question is, if a flow has real-time constraints, can it
trade off bandwidth for a higher packet frequency? If all of the burden
on the network comes from header processing, the answer is no and a
congestion control scheme that reduces packet size instead of packet
frequency is pointless.

I'm wondering if bandwidth is more of a concern when you get closer to
the edge of the network and if yes, what kind of trade-off would be
justifiable.

Stanislav: You're right, streaming audio was not a very good example but
let's take game traffic or VoIP (assuming that their rate can be adapted
to the level of congestion which might not be the case).

Thanks for your comments,
  Joerg