Subject: [Tsvwg] TCP Smart Framing

From: Michela Meo <[email-masked]>
Date: Wed, 16 Jan 2002 15:35:35 +0100

Hi folks,
To revitalize the discussion on the Smart Framing option, let us
summarize 
the discussion so far:
We have been proposing a new segmentation algorithm that exploits
variable segment size. The goal of the scheme is to allow a TCP sender
to trigger fast recovery (FR) even when the congestion window is not
large enough (i.e., smaller than 4 segments).
The major motivations are:
1) The majority of the flow are short, which translates into few
segments
2) "few segments" means that the flow will end before exiting the
initial 
slow start, during which only the retransmission timeout (RTO) can be
used to recover from losses (since the cwnd is small)
3) Fast Recovery (FR) is a much better way to detect packet loss,
especially 
when latency is the major performance index. We feel that this is a real
problem (ever happened to click on a web link and wait 4 seconds before
anything happens? :-))
4) this is again true for every slow start phase, i.e., after every RTO.

Thus, allowing the TCP source to always have at least 4 segments in
flight 
(given that the flow is long enough...) greatly helps the sender to
receive enough acks and eventually to detect segment loss by FR.

Our scheme is engineered so that TCP-SF sender transmits exactly the
same load to the network as a classic TCP sender, so that it perfeclty
mimics its 
behavoiur in term of window growth, congestion control, 
aggressiveness/friendliness.

Some of the people there pointed out that
1) TCP-SF may have problem with the Karn's algorithm
2) By sending more segments, it is less efficient in terms of overhead 
introduced into the network
3) Other proposals (mainly TCPIW) acheive the same results

Summarizing the discussion so far, we can say that
1) as regards Karn's algorithm: TCP-SF must deal with it, and a simple 
modification is required. However, we also pointed out the Karn's
algorithm 
is effective for slow sources, rather than high speed data transfer,
while 
TCP-SF aims at enhancing TCP latency for short lived, http-like, web
traffic. 
Thus they deal with two different problems. However, we foresee no
problems in disabling the SF option when the Karn's algorithm kicks in.

2) Higher overhead introduced. Good point. As usual, you cannot have
your cake and eat it too. 
But this is ONLY true

a) when operating in the "small window" region (i.e., when the cwnd is
smaller than 4). In particular, only 5 more headers are sent considering
the variable size TCP-SF (as 4+4+4 smaller segments will be sent 
per RTT in the small window region versus 1+2+4 segments of a classic
TCP 
sender. After that TCP-SF will behave as a classic TCP sender...). 
Considering TCP-SF with fixed size option, the added overhead introduced
is 
much higher, since 4+8+12 segments are sent on the first three RTTs.

b) when the dropping probability is small. Indeed, TCP-SF is more
efficient in case of packet retransmission. To quantify this, if a
segment is dropped, classic TCP has to resend the whole segment, while
TCP-SF will resend only a small size segment. So if p is the dropping
probability (with the conservative assumption that it is the same for
both full size and small size segments), we have to transmit, due to a
packet loss: 
Classic TCP: (SMSS+Headers) + (SMSS+headers)*p
TCP-SF: (SMSS/4+Headers)*4 + (SMSS/4+Headers)*p
We can now find p=p0 so that the offered load is equal in both cases.
Clearly there is a tradeoff: for p<p0, the overhead introduced is larger
than the one of classic TCP in case of packet drop. But for p>p0, the
overhead introduced using MSS/4 is SMALLER. Considering SMSS~1460, you
can find that p0=~0.1, which amounts to saying that for high dropping
probabilities TCP-SF is more effective than classic TCP in managing
packet drops.

c) Larger number of ACKs on the reverse path. Although this is true, the
reverse path is normally less congested than the forward path.

3) It is true that TCPIW helps the sender in getting more 
packets per RTT. But, as the authors themselves recognize,
a) it is definitively more aggressive than classic TCP
b) it affects the initial slow start only
c) it does not help flows with large MSS (minor problem)

So, to keep discussing about TCP-SF, we'd like to ask you what you think 
about the key ideas and goals that it tries to exploit:
address latency of short lived TCP flows trying to minimize the RTO
penalty, 
using a novel segmentation algorithm.
Any feedback will be greatly appreciated.

Michela, Marco e Claudio

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

---

From: Sally Floyd <[email-masked]>
Date: Wed, 16 Jan 2002 20:38:56 -0800

Michela -

>To revitalize the discussion on the Smart Framing option, let us

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.

If the goal is "to allow a TCP sender to trigger fast recovery (FR)
even when the congestion window is not large enough", Limited
Transmit lets you do this in many but not all cases.  Limited
Transmit sends a new packet (if there is a new packet to send) when
the first and second dup acks are received, so in some scenarios
it lets you keep sending data, and keep the dup-ack clock going,
until Fast Retransmit is invoked.

But there are cases where Limited Transmit wouldn't prevent a
timeout, and SF would.  An example would be when the sender had no
new data to send.  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.

And if the last packet of a transmission is lost, nothing is going
to prevent the need for a timeout, I am afraid.  

...
>same load to the network as a classic TCP sender,...

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.

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

---

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

> new data to send.  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.

As a note, in the draft version of the LT spec we did include
something we called "early retransmit" (if I remember correctly).
The algorithm was basically if (a) your cwnd is <= 3 packets *and*
(b) you have no new data to send then you are allowed to trigger
fast retransmit on cwnd-1 dup ACKs (where cwnd is measured in
segments).  The idea being that if you get a loss with a 2 or 3
packet cwnd and have nothing new to send you will never get 3 dup
ACKs and so you can trigger early.  (OK, maybe not never -- the
network could duplicate an ACK, but that is hopefully rare and
doesn't seem like something to count on! ;)

Mysteriously, consensus for this idea was not reached.  There are,
in fact, re-ordering pathologies that can cause this scheme to
inject a lot of useless traffic into the network.  I would hope that
maybe you could mitigate those.  I still think the idea has some
merit (especially if used with a couple of conditions -- i.e., you
can do it only once per connection or you have to be able to detect
if you're persistently dumping spurious retransmits into the network
and take action to avoid that or ...).

allman

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