Subject: [tcpm] Re: draft-iyengar-burst-mitigation-01.txt

From: Sally Floyd <[email-masked]>
Date: Sun, 29 Jan 2006 22:22:57 -0800

Jana -

>We would appreciate it if you could find the time/energy to review this 
>draft. Though we'd prefer a public review (sent to TCPM), we will value 
>your review as much even if you'd rather send it to us in private.

Here it is.  Thanks for writing this draft, and hopefully starting to
get some progress on these issues.

- Sally
http://www.icir.org/floyd/

Title: TCP Burst Mitigation Through Congestion Window Limiting
Authors: Iyengar, Allman, and Blanton.

I liked this draft, and think it is useful.  And, though it makes
a small change, I think that the mechanism proposed in the draft
is a big improvement over "Use It or Lose it".

First the high-level comments, about active queue management;
rate-based pacing; and security considerations:

* The network's tolerance of burstiness:
The first paragraph of the Introduction says the following: 
  "Bursting can stress network queues causing loss in the bursting
  connection as well as in other flows sharing the stressed queues."

I think it would be useful to add that another important change
that is happening in parallel, to some (unknown) extent, is for
congested routers to use some form of Active Queue Management,
allowing queues in the congested routers to accomodate transient
bursts in the arriving traffic.

Reason 1 for using AQM: Congestion control is more effective if
queues don't giving congestion feedback (in the form of packet
drops) in response to small transient bursts in the traffic.

Reason 2 for using AQM: Even if burst mitigation and rate-based
pacing and all other things are done at the end-nodes, there can
still be burstiness in the aggregate traffic inside the network,
and it would be good for queues to be tolerant of this.

* Rate-based pacing:
The document says that rate-based pacing could be quite effective,
but the implementation can be costly (timers and such).  I think
it would be worth it to say that there are many cases where rate-based
pacing should be a big win over CWL, or over MaxBurst, in terms of
traffic dynamics.  E.g., in a short connection with only BLimit + 1 
more packets to send, but when only one ack will be arriving, due
to ACK losses.  Or when dealing with the significant transient
bursts that can be caused by a connection slow-starting up to a
large window.  CWL and MaxBurst don't prevent the transient bursts
of slow-start at all, but rate-based pacing could work well.  

Of course, it is still a question of whether the benefits of
rate-based pacing are worth the costs in terms of implementation
overhead.  And there is still the old paper by Stefan Savage about
rate-based pacing to deal with, about how rate-based pacing isn't
always a win.  But my suggestion would be to be more explicit about
the potential advantages of rate-based pacing, and to say something about it
a little earlier in the document.

(My current assumption is that connections slow-starting up to large
congestion windows have a large effect on the burstiness of the
aggregate traffic.  I forget, however, what some of the papers about
burstiness-on-small-time-scales have to say about this...)

* Security:  
I think that the security issues raised in Section 5 are pretty
important, and could use more discussion.  This is another case
where rate-based pacing would be more robust than CWL, I think.

Details:

* Causes of micro-bursts:
ACK-compression can also be a cause of micro-bursts.  (That is,
ACK-compression can cause micro-bursts as well as macro-bursts.)

* Section 2, step (1):
"the only case where a micro-burst will not occur" ->
"the only case where a micro-burst will not occur, if steps (2)
  and (3) aren't used".

* "BLimit SHOULD be chosen such that bursts are no larger than those
allowed by [RFC3390]."

Why is this?  It is not obvious to me.  For example, four-packet bursts,
for 1500-byte packets, might be perfectly acceptable, for a connection
that has a sufficiently large congestion window to send that many packets.  
And there is a cost to BLimit being at most three 1500-byte packets.

* Maxburst:
"An additional drawback of MaxBurst ...".
What was the first drawback?  Introducing a separate control?  But
the earlier sentence says that "using two different controls may
make sense".

"the two transmission controllers may interact poorly, causing
undesirable side effects."
Do you have any examples of this?  Or citations?  Or anything
else to back this up?

"When BLimit == MaxBurst, CWL and MaxBurst perform similarly [AB05]."
I don't see how CWL and MaxBurst can perform similarly, and at
the same time you can prefer one over the other.  I think it would
be useful to look a little more closely for performance differences,
or to say that there aren't any.

Depending on how it is implemented, MaxBurst could be made to work
quite well with re-ordering, where each duplicate ack packet (possibly
from reordering of data packets) could be responded-to with up to
MaxBurst data packets (if allowed by the congestion window).
(E.g., Aggressive MaxBurst from [AB05].)
Can something like this be done with CWL as well?

* I didn't go back and re-read [AB05]. so if I have forgotten
something that is answered in that document, my apologies...

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm