Subject: Re: [Tsvwg] TCP Smart Framing

From: Mark Allman <[email-masked]>
Date: Mon, 21 Jan 2002 22:49:54 -0500

> * 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.

Maybe I am missing something here, but why not just use a larger
initial window per RFC 2414 (and soon an updated standards track
version, I believe)?

As for the LW.  Well, this is bogus.  I don't know how else to put
it...

My own hit is that exponential backoff of the RTO is not optional.
It is the last bit of mechanism that helps us in times of severe
congestion.  So, if I take an RTO and retransmit 1*MSS amount of
data in a few packets such that I could recover a loss in the
subsequent RTT with a fast retransmit, that is just wrong.  In my
opinion the only way to recover a loss of a lost packet
retransmitted via the RTO is via another (exponentially backed off)
RTO firing.

You are essentially trying to circumvent exponential backoff.  If we
get in that regime, we need to be there.  Period.

> 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.

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).  One option that has been suggested
is to allow a FR on < 3 dup ACKs once per connection as a cheap way
to help most connections (since most connections are short).  A
better way (in my opinion) would be to use some sort of Eifel or
DSACK-like scheme to ensure that you are not sending a ton of
spurious retransmits -- in which case you could use a dup ACK
threshold of < 3 during the entire connection if your cwnd was
small (and your mechanisms indidicated no (or almost no) spurious
retransmits). 

> 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.

I also do not buy that 4 little packets == one big one.

My understanding of routers is pretty rough.  So, someone can
correct me if I am wrong here, but here is my understanding of how
they work (very crudely)...  You allocate memory for a queue in
terms of "slots".  Each "slot" can hold one (MTU sized) packet.
Every packet that comes into the router gets a slot.  If it fills
the slot, fine.  If it doesn't, fine.  All packets get one slot.

So, consider an example where a router has a queue of 10 packets and
I send the first bit of data from a TCP connection I have setup.  In
the SF case the data arrives and takes up 4 slots.  In the standard
case the data arrives and takes up 1 slot.  The slots are used for
as long as it takes to send the 10 things in the queue.  And, for
this amount of time the router is more congested with SF than
standard TCP.  So, as more stuff comes into the queue the chances of
dropping increase more with SF than with standard TCP.

It is interesting that this enhanced loss recovery algorithm
actually *increases* the chances of loss.

At the very least I think you should be considering the downsides of
SF in terms that go beyond the additional packet header overhead.

allman

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

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

---

From: Stephen Bailey <[email-masked]>
Date: Tue, 22 Jan 2002 18:03:32 -0500

> My understanding of routers is pretty rough.  
> [...]
> All packets get one slot.

They actually work about every different way you could imagine, so
it's probably sound not to reason about them much one way or the
other.

Most `new' routers (with hardware-based forwarding planes) don't use
the one slot per packet technique because it results in a substantial
waste of buffering space if the packet stream has many small packets.
Slot-based design usually assume they are only queuing a small
amount of data internally, as might be the case in an older Ethernet
switch. 

There are typically some slotish things in the header processing
parts, but they are provisioned to handle minimum sized packets at
line rate.  In some architectures if you start to turn on a lot of
per-packet features (policing, classification, counters, etc.)  you
may see a (mild or severe) degradation in forwarding performance as a
function of packet rate.

Steph

---

From: Michela Meo <[email-masked]>
Date: Thu, 24 Jan 2002 13:59:51 +0100

> initial window per RFC 2414 (and soon an updated standards track

True. This affects all TCP versions, and then all TCP versions will be
able 
to take advantage of "increased initial window". 
However, TCP-SF will start sending always 4 segments, whatever the
MSS, while 
"classic" TCP will start sending either 4, 3 or 2 segments depending
on the 
negotiated MSS... 
Still, if limited transmit is implemented/enabled, it will  take (at
least) 
one more RTT to trigger Fast Recovery in case of packet loss...

> it... My own hit is that exponential backoff of the RTO is not optional.
> subsequent RTT with a fast retransmit, that is just wrong.

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. 
On the other hand, if there's congestion such that the "optimal" 
value of the CWND is really small,  i.e., smaller than 4*MSS, then 
Classic TCP's only chance to detect a  segment loss is to use a RTO! 
TCP-SF (and Limited Transmit too...)  allows the sender to receive 
more feedback, _WITHOUT_  increasing the offered load to the
bottleneck link.

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... 
again (MSS/4+headers)*4 + (MSS/4+headers)*P < (MSS+headers) +
(MSS+headers)*P 
if P is large...
This will reduce the (bytewise) offered load to the congested link,
and 
thus will alleviate the congestion ...

This is if routers are bandwidth-limited. If limitations are due to
packet-
processing time, we agree with you that TCP-SF may pose some problems. 
In the latter case, you should blame to your network solution vendor!
:)
As several people on this mailing list pointed out, nowadays routers
are
engineered so that they can easily switch batches of short packets at
linespeed...

If the sender enters that regime it is because CWND=1MSS is too large,
so 
one had better send smaller-size segments, to ensure that at least a 
portion of data arrives to the receiver. Also the sender has the
chance 
to keep sending smaller-size segments, instead of retrying sending 
1 full-size segments.

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

> small (and your mechanisms indidicated no (or almost no) spurious

Is this any simpler than keeping the dup-ack threshold at 3 and using 
Smart-Framing? 

> I also do not buy that 4 little packets == one big one.

Indeed, 4 little packets is better than one big packet :-)

> the slot, fine.  If it doesn't, fine.  All packets get one slot.

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.

> actually *increases* the chances of loss.

One cannot fail to notice that "Increasing TCP initial window" does 
exacly the same...

> SF in terms that go beyond the additional packet header overhead.

We took care of these issues in the first version of the I-D, as 
well as in the Globecom paper.
(http://www1.tlc.polito.it/mellia/papers/globecom01_TCP-FS.pdf)

Michela, Marco and Claudio