Subject: Re: [Tsvwg] new I-D for Smart Fragmentation of TCP segment

From: "Claudio E. Casetti" <[email-masked]>
Date: Thu, 06 Dec 2001 14:56:10 +0100

Joe Touch wrote:

> > We agree with you that this is a delicate issue, and also Sally Floyd pointed
> > out this issue. However
> >
> > - most of the current IP stacks use a 1500 MTU, which translate into about
> > 10% overhead for 375 small size MTU. This can be explicitely taken into
> > account into the TCP-SF draft, which may be enabled only id SMMS >
> > thresholds...
> 
> IP's largest common MTU is 576. Microsoft uses 576 for PPP (the vast
> majority) of connections.
> 
> Back in 1997, there were stats posted at NLANR that 85% of the packets
> were 576 or smaller. http://www.nlanr.net/NA/Learn/packetsizes.html
> 
> Newer measurements from CAIDA reinforce this point
> http://www.caida.org/analysis/AIX/plen_hist/.
> 
> If you have other data to back up an alternate view, please let us know.

Indeed, we do. You can take a look at the following web pages:
http://verza.polito.it/tsol/sample/index.html
http://verza.polito.it/tsol/sample/node4.html
http://verza.polito.it/tsol/sample/node5.html

These stats refer to online measurements taken over our campus network
in different (recent) time periods. 
We are setting up an interactive online version of these measurements, which
allows you to customize the stats you would like to see. This is also
available at: http://verza.polito.it/tsol/main.php

In a nutshell, these stats show that around 75% of flows negotiate an MSS of ~1500B.

Regarding Microsoft's MTU settings, we found that:

* By default, the Windows 95 MTU is 1500 over any type of connection
* Win98 and WinME let the user choose among these MTU options:
    - Automatic    this is the default setting
    - Large        1500
    - Medium       1000
    - Small        576
  When you use Automatic mode, all Point-to-Point Protocol (PPP) connections at 
  speeds below
128kbps are made with an MTU of 576. At speeds above 128kbps, 
  all connections are made with an MTU of 1500.
  (see http://support.microsoft.com/default.aspx?scid=kb;EN-US;q183437)
* Although we found no MS document to back this, we experiment with WinNT, Win2000
  and WinXP and found that the default MTU over modem-speed PPP is 1500 B.

So, our opinion is that, in the near future, the default Internet MTU will more and 
more be 1500B rather than 576B.

> 
> > - Moreover, TCP-SF will switch back to full size MSS as soon as CWND>=4SMSS.
> > In particular, considering the variable size version, at the beginning of
> > each slow start, the number of segments used to send _exaclty_ the same
> > payload is 4+4+4 instaed of 1+2+4 before switching back to full size SMMS...
> > that is only 5 headers more than classic TCP. The fized size implementation
> > will send 4+8+(12+1) segments...
> 
> This should be in the draft, at least.

Ok, in the next version.

> > - ... But notice that in case of segment drop, the retransmission of smaller
> > segments is more efficient than having to resend a full-sized SMSS (again,
> > this is a bit blunt put in this way, but in the rejected Infocom paper we
> > analytically evaluated such gain). In a nutshell, the throughput gain of
> > SF-TCP over Classic TCP in the small-window regime grows with the segment
> > loss probability, thanks also to the smaller bandwidth waste due to
> > retransmission.
> 
> This assumes that the loss is helped by using smaller retransmission
> packets. If queues are RED per-packet or tail drop, this will not matter.

Our point was this: you lose a small packets, you retransmit a small packet, hence
less bandwidth waste.

> > - (ok, this is straighforward) smaller-sized segments exploit pipelined
> > transmission especially in long-latency, slow links (such as modems)
> 
> But they also increase overhead. Since these links are from the host,
> packets aren't dropped entering the links, which means the packet size
> is irrelevant unless the link is so noisy that's where the drops are (in
> which case you have much larger problems), or you're running a true
> router at home.

The packet size is not irrelevant, especially on slower links. Since there 
is store-and-forward in routers, the smaller the segment, the
faster it is stored and then forwarded.

> > They can work coupled and coexist... Why ruling out proposing TCP-SF as a
> > future enhancement?
> 
> Unless there is a substantive need, TCP (and most protocols) are better
> off when simple, rather than having every possible 'feature'. 

Well, as far as simplicity is concerned, TCP-SF is but a few lines of code.
Compare it to SACK :))

> > Let us rephrase this: TCPIW allows the Initial and Restart window to be equal
> > to i.e. 4 SMMS. The Loss Window must be set to 1 SMMS. On the contrary, a
> > TCP-SF sender must use small-sized segments EVERY time the current cwnd is
> > smaller than 4SMMS, including then the Loss Window. This enables Fast
> > Recovery for senders who experienced an RTO, alleviating the sender latency.
> 
> That could be perceived as violating the Loss Window intent - to inject
> only ONE packet into the network. TCPSF's loss window should be one
> small packet, in that case.

In RFC2581, it is said that: "upon a timeout cwnd MUST be set to no more than the loss
   window, LW, which equals 1 full-sized segment (regardless of the value of IW)".
The RFC does not mention the need to have one PACKET.

> > True, but for such short lived flows, waiting for 3-second RTO is a HUGE
> > time... That's the main reason why TCP-SF outperforms 'Classic TCP' when the
> > completion time is used as performance figure, even if the dropping
> > probablility is small. We feel that avoiding this penalty is important,
> > probably more than guaranteeing larger throughput to long-lived flows...
> 
> Do you have stats on how many of these short lived connections suffer
> RTO timeouts, and the quantitative improvement of sending small packets
> on that probability?

Regarding the first request, you can check Figure 1 in
http://www1.tlc.polito.it/mellia/papers/globecom01_DiffServ.pdf 
which shows the completion time of different classes of flow lengths.
The improvement of the completion time on the same scenario using 
TCP-SF or Classic TCP is in Table I in our Draft.

> > Actually, models and simulations show that TCP completion time already 
> >improves when the dropping probablity is 1 %, or if the bottleneck 
> >utilization is over 50% ...
>
> 1% is fairly high too. I'm not clear what the bottleneck utilization
> here refers to - how many flows were aggregated over the bottleneck in
> the simulation?

OK, you can refer to 
http://www1.tlc.polito.it/mellia/papers/globecom01_TCP-FS.pdf
for further details.

> > One segment or one SMSS-worth of data split into more than one segment? :-)
> 
> That's a good question - as above, it depends on whether you're packet
> or bandwidth limited. With tail-drop or packet-drop RED, you SHOULD be
> sending one segment. If you can ensure E2E byte-drop RED, then it's not
> clear which is better. However, you SHOULD be sending 1 SMSS total -
> i.e., taking 1000 bytes + 40 byte header into 4 packets SHOULD result in
> a total of 1040 bytes, i.e., 250+40, 250+40, 250+40, and 130+40
> (actually, you SHOULD subtract off your link headers as well). You
> SHOULD NOT be sending more data into the network due to the headers.

We don't foresee any problem in reformatting the packet size to take into
account the overhead. This can be in a future version of the Draft.

> > Correct us if we're wrong, but it doesn't seem to us that the sender needs to
> > have knowledge of WHEN the acked segments were sent. What Nagle really cares
> > about is the amount of data buffered at the sender and when to send new segments.
> 
> If this is true, then it would need to be validated and incorporated
> into the ID. I suspect that there will be problems when TCP-SF
> fractioning is activated during a pending-small-segment episode.

Ok, we already acknowledge this is a subject of future research.

Thanks again for taking the time to answer.

Ciao,
Claudio, Marco, Michela

-- 
+------*<>*--------->*<>*<>*<>*<>*<>*<>*<>*<-----------*<>*--------+
| When I'm in bear country I like to be surrounded by people who   |
| can't outrun me         - Scott Adams                            |
+------------------------------------------------------------------+
|                      Claudio Casetti                             |
| Politecnico di Torino          Home Page:                        |
| Torino - Italy                 http://www1.tlc.polito.it/casetti |
+------*<>*--------->*<>*<>*<>*<>*<>*<>*<>*<-----------*<>*--------+

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Dec 2001 08:27:31 -0800

> Joe Touch wrote:

...

> in different (recent) time periods. 

The measurements above are from core network access exchanges. They 
aren't comparable to a campus snapshot.

Do you have any data to back up how this will affect the Internet as a 
whole??

> Our point was this: you lose a small packets, you retransmit a small packet, hence

Some data to back this up would be useful as well. Have you compared the 
overhead of additional packets and the utility of retransmitting 
portions? Or whether the probability of packet loss is related to packet 
size? (e.g., a 1ms burst error might kill two small packets or one large 
one just as easily)...

> faster it is stored and then forwarded.

Where fast = low latency, I'll agree. However, given RTTs in the dozens 
of packets, lowering the latency by 3/4 of one packet is noise.

Are you thinking of some other definition of fast?

> Well, as far as simplicity is concerned, TCP-SF is but a few lines of code.

SACK was shown useful in a large number of simulations and real 
measurements. This isn't the case yet here.

> The RFC does not mention the need to have one PACKET.

OK - my slipup- one full-size segment. You're sending 4 smaller 
segments. That seems in conflict still.

Thanks for the additional clarifications, as well...

Joe