Subject: [Tsvwg] TCP Smart Framing

From: Michela Meo <[email-masked]>
Date: Mon, 21 Jan 2002 16:07:16 +0100

Sally Floyd wrote:
>
> Michela -
>
> >To revitalize the discussion on the Smart Framing option, let us
> >summarize
> >the discussion so far:
>
> I have not followed this discussion in complete detail, but I would
> suggest that in summarizing the discussion so far, it would also
> be useful to summarize the relationship of SF with Limited Transmit
> (LT), RFC 3042, which has been Proposed Standard for a year now.

As Sally suggested in her last email, we're listing a few points
that we believe can summarize the relationship between Limited
Transmit and Smart Framing:

* Reaction time: in the small window regime (cwnd <= 4MSS), in a
single-drop scenario, it can take LT between two and three RTTs
before enough dupACKs are available to trigger FR. Conversely,
TCP-SF just needs one RTT before FR can be triggered.

* Small windows: LT does not prevent a timeout if IW=1 or when
TCP restarts with LW=1. TCP-SF always prevents timeouts in single-
loss scenarios, whatever the size of cwnd.

* RTT estimation: TCP-SF's "hidden agenda" includes the refinement
of the RTT estimate (hence possibly shorter RTO) early on in a
connection, thanks to the higher number of RTT samples. LT does not
achieve this.

* no new data: as already pointed out, not enough new data may be
available to keep the ACK clock going, i.e. because the original
file was too short; the position (inside the window)
of the dropped packet may exacerbate this problem. Such shortage
might affect TCP-SF too, though the higher number of segments makes
this
occurence less likely. Of course, if one of TCP-SF's last segments
is dropped, timeout expiration cannot be helped.

As an aside, it's probably a good idea to consider the coexistence of
LT and TCP-SF, whose joint deployment would trigger FR even in
multiple-drop scenarios.

> But instead of using smaller-than-normal packets
> to induce a Fast Retransmit, it might be better to ask the question:

> if you get a single duplicate acknowledgement, and there is no new
> data to send, should you be able to retransmit old data that might
> or might not be lost?  A "yes" answer to this question would take
> care of many of the additional cases where Limited Transmit in its
> current form is not sufficient to prevent a timeout, without
> unnecessarily reducing the packet size, and without increasing the
> number of packets used by all connections when they have small
> windows.

In our opinion, retransmitting old data is dangerously close to
getting rid of timeouts and using single dupACKs as drop
indicators. As Mark Allman himself pointed out, this should
probably be a once-per-connection solution.

> I don't buy it that four small packets presents the same load to
> the network as one larger packet.  Aside from the issue of header
> size, there can be router limitations in terms of packets per second

> processing capacity in addition to the link bandwidth limitation
> in terms of bytes per second.  It is still not clear (to me) which
> limitation, packets per second or bytes per second, is likely to
> dominate some years in the future.

Agreed, the overhead is the price you pay. However, one has to wonder
whether processing capacity is going to be the bottleneck, even in the

near future.

Michela, Claudio and Marco

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

---

From: Mark Allman <[email-masked]>
Date: Thu, 24 Jan 2002 09:30:41 -0500

> Still, if limited transmit is implemented/enabled, it will take
> (at least) one more RTT to trigger Fast Recovery in case of packet
> loss...

Why is this a huge problem?  It's not like TCP is sitting around
doing nothing.  It is doing something useful while trying to elicit
these additional ACKs.  Sure, there is a modest delivery penalty to
the application, but is this really that big of an issue?

> We agree that the RTO mechanism is essential in times of severe
> congestion.  However, if the congestion was so severe, it is
> highly likely that not even TCP-SF will get away without dropping
> more than one small segments, and therefore RTO will fire using
> the backoff mechanism.

Two points...

  * First, I'd rather not bet on "highly likely" after an RTO.

  * Second, even if you drop more than one segment after an RTO you
    can still fast retransmit.  Consider sending your four small
    segments, with the second two being lost.  The first two are
    ACKed, which sends out new data that can then trigger duplicate
    ACKs.  Especially if you consider limited transmit in
    conjunction with this.

And, even if we discount the second item as an edge case, I still
think that a loss of an segment resent via RTO must be recovered via
another (exponentially backed off) RTO.  This is not the place to
add aggressiveness.

Think about it another way...  If we're in this small window case
with SF and we take an RTO that means the congestion has already
proved too much for SF to successfully handle.  So, why would it be
appropriate to be anything but very conservative?

> On top of that, TCP-SF will definitively be more efficient under 
> heavy load/ high drop probability, as the sender will have to resend 
> only one fourth of data... 

Which matters on bandwidth dominated paths, but not on delay
dominated paths.

> In other words, TCP-SF is giving the sender the chance to operate
> with a granularity equal to MSS/4.

Yep.  So, the real question is whether this is useful.  On the one
end we can operate at the path MTU.  On the other end we can send 1
byte per packet.  Those are the bounds.  From the packet processing
and overhead standpoints we want to be at the MTU-sized packets end
of things.  From the standpoint of wanting to retransmit the least
number of bits and generate the most duplicate ACKs we want to send
1 byte per packet.  Packet sizes in the middle are a mix of
tradeoffs.  

So, my question on this remains: Is there a compelling reason to
move from the MTU sized packets?  I, personally, have not yet been
convinced.

> > You missed the point.  What I said was that reducing the duplicate
> > ACK threshold should be done only if we can be sure that we're not
> > in a situation where we are persistently sending spurious
> > retransmits (due to reordering).  
> 
> Is this any simpler than keeping the dup-ack threshold at 3 and
> using Smart-Framing?

???

I don't know.  I don't think of either of them as terribly hard.
And, some of us want to be able to track spurious retransmissions
and hence would have most of the necessary machinary for doing what
I suggested in place already.

> This is not true, as already pointed out by other people on the
> list.  There are architectures out there that are working like you
> are saying. But there are also architectures where buffers are
> partitioned in variable-size chunks.  In this case, small-sized
> packets will suffer a lower dropping probability.  And given that
> a flow will use small-sized packets only when it is in the small
> window regime (and thus sending at low rate, and sensitive to
> packet drop), it is much better for the network to force
> large-window (and thus higher-rate, more bandwidth-consuming, more
> reactive) connections to slow down.

What I took away from the comments was that there are bunches of
different schemes in use and making any one assumption is dicey.
That seems reasonable to me.  So, I think that means that you need
to think about the case when the router is setup as I described and
we need to think of the impact on queueing and congestion in that
case.

> > It is interesting that this enhanced loss recovery algorithm
> > actually *increases* the chances of loss.
> 
> One cannot fail to notice that "Increasing TCP initial window"
> does exacly the same...

(True -- all the measuerments I have seen show this.  At the same
time, we never claimed it to be a better loss recovery mechanism.)

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/