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

From: Sally Floyd <[email-masked]>
Date: Wed, 22 Feb 2006 16:09:22 -0800

>> * The network's tolerance of burstiness: [...]
>
>I have added some text (based on your suggestions) that now seems more 
>appropriate in the Discussion section (Section 4). I have also changed the 
>tone somewhat... I do not stress the fact that increased deployment of AQM 
>is happening (which I think was one of your points, correct me if I read 
>wrong). The reason I changed the tone was to maintain focus on micro-burst 
>mitigation, while mentioning the parallel effects of AQM. Let me know if 
>you think the following captures it, or if you'd suggest mods.
>
>     We emphasize that the question of whether or not micro-bursts need
>     mitigation remains open. While use of micro-burst mitigation can
>     reduce stress on network queues, congested routers may, in parallel,
>     use some form of Active Queue Management (AQM) to better handle
>     stress on network queues. Use of AQM in a router allows for better
>     congestion control through better congestion signals (i.e., signals
>     other than packet drops) and enables queues to accomodate transient
>     bursts in the aggregate incoming traffic. Micro-burst mitigation may
>     still provide some respite by reducing the amount of transient
>     burstiness in the traffic aggregate at a queue.

Yep, that sounds good to me.

>> * Rate-based pacing:
>> [...] 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. [...]
>
>I have modified the para in the Related Work Section (Section 3) to 
>reflect your suggestions. Also see the following argument.
>
>       * Rate-Based Pacing [VH97] imposes a limitation on the rate of
>         sending, and prevent bursts by pacing data into the network
         until the ACK clock is established.  Although this solution can
>         be very effective in burst mitigation in some cases, it requires
>         a new timer and parameters for pacing out the data segments.
>         Further, as shown in [AB05], there are cases where there is no
>         natural "lull" in the connection into which segments can be
>         nicely paced, and as shown in [AST00], the tradeoffs involved in
>         using pacing are not clear.  While the exact application of
>         pacing clearly requires more research, there are several cases
>         where pacing can be expected to mitigate bursts better than CWL
>         (or MaxBurst or UI/LI). For instance, where CWL (also MaxBurst and
>         UI/LI) will not be able to handle bursts caused by slow start,
>         pacing could work well and prevent these transient
>         bursts. Pacing can potentially also have a bigger impact on
>         traffic aggregates, possibly significantly reducing burstiness in
>         the aggregate at several timescales.
>
>> 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.
>
>I do not use this example, because I am not sure how RBP will be in short 
>connections, i.e., I am not clear on the tradeoffs here---for instance, 
>what happens if the RTT value is seeded incorrectly in such a small 
>connection? But I believe the larger point you wanted to convey has been 
>captured in the para above. Let me know if not.

That sounds fine to me.

>> 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.
>
>I hope that para was able to capture it, but I'm not sure about saying 
>something earlier in the document. This section is the first place that 
>the other algorithms are mentioned and the pros and cons discussed. Do you 
>think the entire section should appear earlier?

No, I think it is fine.

>> * 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.
>
>I'll try to add more discussion on that point. Do you have anything 
>specific in mind that you might want to suggest?

Nope, not really.

>While I suspect that rate-based pacing may be more robust than CWL under 
>ack loss, it is difficult for me to make a strong comparative statement 
>without knowing what exactly would be used for rate-based pacing. 
>Depending on the exact details, I suspect that rate-based pacing *could 
>also possibly* be (differently) susceptible to issues such as ack loss. 
>So, I am not sure that we should say anything about how the mentioned 
>security issue applies to rate-based pacing.

I disagree.  The point of this paper is not be be a used-car salesman
for CWL (sorry), the point is to evaluate CWL as fairly as you are able,
including considering its weaknesses, and considering when alternate
proposals might be more robust in some particular respects.  If you
"suspect that rate-based pacing may be more robust than CWL under
ack loss", or under reordering of data or acks, then I think it
would be good to think about it a bit, and to say something.  The
question isn't whether it would be *possible* to design a rate-based
pacing mechanism that would share the same weaknesses, but whether
it would be *possible* to design a rate-based pacing mechanism that
didn't.  In my opinion.  

>> * 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.)
>
>How so? I am thinking about it, but cannot figure out how that could be.
>A micro-burst is defined as a burst sent in response to one ACK. In time,
>I suppose ACK-compression could cause bursts at the same timescale. In
>other words, some macro-burst phenomena could occur at the timescales that
>the bursts resemble micro-bursts. Maybe we should state that explicitly in
>the discussion about macro-bursts. Something like
>
>"Note that some macro-bursts could occur at the timescales of
>micro-bursts---for instance, back-to-back ACKs due to extreme
>ACK-compression could cause the consequent data burst to resemble a
>micro-burst from the network's point of view."
>
>What do you think?

My advice would be to broaden your definition of micro-bursts to include
bursts on small time scales due to ACK compression.  Then you could
talk about which mechanisms do or don't ameliorate the bursts due
to ACK compression...

...
>> * "BLimit SHOULD be chosen such that bursts are no larger than those
>> allowed by [RFC3390]."
>>
>> Why is this?  It is not obvious to me.
>
>I was thinking about a fixed burst limit that one could apply for
>line-rate bursts, and it seemed reasonable to use 3390 as a basis. My
>(simplistic) reasoning was that since bursts from starting TCP connections
>should be absorbable by the network, 3390-defined bursts should be
>acceptable in general.

I might be worth talking about the potential costs of an
unnecessarily-small burst limit, so that it is clear that it is
a case of making a tradeoff somewhere.  

>> 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.
>
>I'm not sure I'm following. A large cwnd does not mean more segments can
>be sent (at line-rate) in response to _each ack_. BLimit is meant to
>impose that limit, not to limit the overall cwnd size. IMHO, having a
>large cwnd does not mean that a large burst is acceptable.

When you say that "BLimit SHOULD be chosen such that bursts are no larger
than those allowed by [RFC3390]", you are saying that
BLimit should not allow micro-bursts of four 1500-byte packets, but
should only allow micro-bursts of three 1500-byte packets, right?
I am just asking what is wrong with a micro-burst of four 1500-byte
packets?  (For a connection that has a congestion window large
enough to send four 1500-byte packets.)  I understand that BLimit
doesn't limit the overall cwnd size.
 
>Yes, I agree that there is a cost to having BLimit at what it is. But is
>there a situation that demands larger line-rate bursts?

Yep, consider a connection with only four 1500-byte packets left
to send, but only one ACK coming in (because delayed ACKs are used,
and one of the last two ACKs was dropped or reordered).  

>What do you think is a reasonable limit (static/dynamic)? I may not be
>following what you are saying; if so, let me know.

My own vote would be to set BLimit to at least four packets, regardless
of packet size.  Maybe even five 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".
>
>New text:
>However, a drawback with
>MaxBurst is that adding a second control brings with it the
>possibility of the two transmission controllers interacting
>poorly to cause undesirable side effects.

I still don't buy it.  You have said elsewhere that 
"When BLimit == MaxBurst, CWL and MaxBurst perform similarly [AB05]."
Except that you think that MaxBurst might have a fatal flaw not
shared by CWL, you just haven't run across it yet?  Because you can
bring up the language of "two controllers interacting" for MaxBurst?
I don't buy it.  [Just as an aside, after the sentence above,
you could mention Aggressive MaxBurst, which improves on CWL by 
being robust to reordering.]

>> "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?
>
>Not really. The idea was to suggest that there is the possibility of poor
>interaction due to the introduction of a new control. Maybe the new text
>(see above) captures this more effectively?

As I said above, I don't buy it...

...
>> 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?
>
>Hmm. Offhand, I do not see how this can be done with CWL, but I will think
>about it more. This is a good point though. Maybe we should mention this
>in the related work section where we discuss pros and cons of MaxBurst.

I think that would be good.

Regards,

- Sally

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Feb 2006 21:20:59 -0800

Sally Floyd wrote:
...
> of packet size.  Maybe even five packets...

The reason we chose that number is documented in our earlier ID. IMO,
much of that discussion is directly relevant to this work. In fact, I
can't see why this algorithm was derived from CWL vs BOL.

...
>> in the related work section where we discuss pros and cons of MaxBurst.

That too would be a good place to consider the discussion in the earlier ID.

IMO, it would be useful to merge those two documents to move forward,
since that doc had a much more detailed discussion of these alternatives.

Joe