Subject: Re: pilc minutes for IETF 48

From: Vernon Schryver <[email-masked]>
Date: Mon, 9 Oct 2000 11:34:44 -0600 (MDT)

> From: Bill Sommerfeld <[email-masked]>

> > What is the cost of out-of-order delivery?  As far as I know, IP packet
> > re-ordering has at most the following costs:
> > 
> >   - broken IP fragmentation code goes crazy
> >       this is surely not a consideration
>
> related, but slightly different:
> 	- broken packet filtering code goes crazy when fragments are
> 	  reordered. 

Yes, but also not a concern, right?

> >   - TCP goes slightly slower, and with sufficient consecutive out-of-order
> >      segments, can send duplicate ACKs which can cause retransmissions.

In thinking about possible responses to my objections to worrying about
that, I've thought of other real life things.  If the worry is that
wireless base stations will have more than 4 MSS's of queue for each TCP
stream (or a common queue for all streams bigger than 4 MSS's), and if
link-layer retransmissions can cause out-of-order delivery and so
fast-recovery/fast-retransmit, then there is an obvious fix that probably
needs doing regardless of wireless ARQ.

4 of today's MSS's is about 6 KBytes, which is a lot more than 0.5
seconds at 14 kbit/sec.  Regardless of wireless ARQ triggering
false fast-retransmit, I wonder if you really want that much queue space.

It is a Bad Thing(tm) for any router to have a queue that is too big.
Too much queue space in the path causes bad things in old fashioned land
lines.  It's important for routers to signal the end points when their
queues are big, and without ECN, that is done by dropping packets.
For an example of the results of that Bad Thing(tm),
 - build a cross country intranet that includes a 56kbit/sec link.
 - configure the routers on the ends of the 56k link to have 60K bytes
     of queue.
 - put hosts on both ends of the path with default TCP windows of at
    least 60KBytes
 - have one or two hosts do bulk transfers (e.g. move 600 MByte CDROM
    imags) while the other hosts do interactive things such as rlogin,
    telnet, DNS, and HTTP.
 - run `ping` to watch latencies for the interactive jobs
You'll find that the interactive jobs experience latencies that vary in
a sawtooth between the speed of light and serialization delays (e.g. < 80
ms) and more than 10 seconds (10,000 ms).  The solution is fix the routers
so that they can tell the bulk transfer hosts to back off, and that is to
reduce the queue sizes at the ends of that 56 kbit/sec link from
10 seconds * 56 Kbit/sec to about 0.5 seconds * 56 kbit/sec.

I've been painfully explicit and used strange values like 56 kbit/sec
because I've "been there and done that" in real life.  It should be easy
to adjust those strange old numbers to match modern wireless links.

Just because DRAM is almost free today does not mean that you should use
GBytes of it for queuing in wireless base stations.  It is important for
wires base stations to signal their congestion, and since you will not
always have ECN to all hosts, you must drop packets, and that means you
must not have too much queing.

Vernon Schryver    [email-masked]

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 11 Oct 2000 15:57:18 +0200

>queues are big, and without ECN, that is done by dropping packets.

I fully agree but also think that this is already discussed in the "Advice 
for Internet Subnetwork Designers" ID.

>The solution is fix the routers

If you further restrict this to say that this is the upper limit *per 
flow*, I would fully agree with you again.

The upper limit for the number of bytes allowed for queueing at a link per 
flow before dropping occurs should be "fixed worst-case e2e RTT" x link speed.

You have picked 500 ms for the value of "fixed worst-case RTT". That would 
be fine with me but might be argued ...

>must not have too much queing.

I think this is already the message of the "Advice for Internet Subnetwork 
Designers" ID. What is still unclear is a rule-of-thumb for the 
dimensioning of the queueing buffer as discussed above.

///Reiner

---

From: "Franco Carducci" <[email-masked]>
Date: Thu, 12 Oct 2000 15:25:34 +0200

Hi all,

I suppose the item in subject has been already deeply analysed (pros and
cons): someone could point me to
those evaluations?

Thank you very much
Best regards

*************************************************************
Franco Carducci
Alenia Spazio SpA
Via G. V. Bona 85 - 00156 Roma - Italy
Phone: + (39) 06 4151 457  Fax: +(39)06 4151 471
E-mail: [email-masked]
Web:  www.alespazio.it

*************************************************************