| Gerrit -
|
| I have revised draft-ietf-dccp-rfc3448bis-02b.txt
|
("http://www.icir.org/floyd/papers/draft-ietf-dccp-rfc3448bis
-02b.txt")
| to say the following:
|
| However, the TFRC sender is not allowed to accumulate
| `credits' of more than max(t_ipi, t_gran) time units in packet
| scheduling, so the sender is not allowed to send arbitrary
bursts of
| packets after idle periods.
|
| If you could read Section 4.7 on "Scheduling of Packet
Transmissions"
| and see what you think, that would be great.
Idle periods are not the only possible cause; timing inaccuracies and
slow sending
rate achieve the same effect over time.
Using max(t_ipi, t_gran) allows large bursts again. On Gigabit
networks,
t_ipi = 100 usec (or less) is not unusual. If t_gran = 10ms, then send
credit
builds up until t_gran is reached, which means that the sender can
always send bursts
of up to 100 packets or more (t_gran/t_ipi) at once.
Yep. That was the point. Consider Case 1 and Case 2 below:
Case 1: a high-bandwidth flow, no congestion, MSS-sized segments.
One problem is what to do when t_gran is 10 ms and t_ipi is 1 ms.
Assume that there is no congestion, and the application is using
MSS-sized
segments. Does the TFRC sender only get to send two packets every
10 ms? Or does the TFRC sender get to send ten packets every 10 ms,
as needed to achieve its TFRC-allowed sending rate of 1000 packets
per second?
(TCP in this case would send as many packets as allowed by cwnd
each time it got a chance to send, with TCP as currently standardized
(i.e., not limited by rate-based pacing or maxburst or some such).
So the above is no worse that the short-term burstiness of TCP
with a CPU-limited sender.
Case 2: a high-bandwidth flow, a transient shortage of CPU cycles
at the sender.
What if the TFRC sender usually sends one packet each time
its turn at the CPU comes up, but there is a transient period
when the CPU is very busy with something else, and when
the TFRC sender's turn at the CPU comes around again,
it has a backlog and would like to send all K backlogged
packets. Does it get to? Or does it have to pace them out?
Of course, there are complications that are not addressed
in the language above:
Case 3: a high-bandwidth flow, no congestion, small segments.
We don't want to encourage a flow to continually sent many small
packets each time its turn at the CPU comes around, when it
could instead sent fewer large packets with essentially the
same one-way packet delay from the sending app to the
receiving app. My language above doesn't address this.
Feedback?
(I tend to work in the world of models and simulators, so
I could be missing something essential. I am also cc-ing this
to Mark Handley, who I believe was the author of the
original text in RFC 3448.)
- Sally
http://www.icir.org/floyd/
