Subject: Re: pilc minutes for IETF 48

From: Vernon Schryver <[email-masked]>
Date: Wed, 11 Oct 2000 08:23:49 -0600 (MDT)

> From: Reiner Ludwig <[email-masked]>

> > > As soon as the link's capacity goes beyond 4x MTU, any link layer
> > > retransmission would cause a *spurious* fast retransmit / fast recovery in
> > > TCP. That assumes that (1) the following 3 packets do not incur a link
> > > layer retransmission and (2) out-of-order delivery is permitted even 
> > within
> > > a flow.
> > >
> > > For some wireless networks this could become a real pain ...

> ...
> OK, so my wording was a bit loose. With the "link's capacity" I mean the 
> number of TCP segments (MSS) that fit into a *link layer RTT*.

Given the speed of light and so forth, that must mean that the near end
of the link has buffering of at least 4x MSS.  The MSS is at least 1500,
so 4X is 6 KBytes, and 6 KBytes at 14000 bit/sec is 3.4 seconds.

] From: Reiner Ludwig <[email-masked]>

] >It is a Bad Thing(tm) for any router to have a queue that is too big.

] ...
] 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
] >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.
]
] If you further restrict this to say that this is the upper limit *per 
] flow*, I would fully agree with you again.

If each flow gets fair access, then yes.
Otherwise, the limit must be shared by all flows.

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

I wouldn't argue against any reasonable value.  50 ms is too small.

5000 ms (or 3400 ms) is intolerable to essentially everyone.  See the 25
year old human factors studies on the upper bounds for responses from
timesharing computers.
Many people are unhappy with total (not just per-link) RTT's above 300 ms.

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

In that case, what is this about a link having so much buffering
that its RTT is 4X MSS?

Vernon Schryver    [email-masked]

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 12 Oct 2000 16:15:41 +0200

>so 4X is 6 KBytes, and 6 KBytes at 14000 bit/sec is 3.4 seconds.

Good point. Although I don't agree to the "... must mean that the near end
of the link has buffering of at least 4x MSS".

It means that the link layer sender can have 4x MSS worth of bytes in 
flight, i.e., unacked at the link layer. That sender would not need to have 
any queue at all if it received the next packet from the higher layer (IP) 
just when it has sent out the (last bit of the) preceding packet/frame.

Instead I would say "... the near end of the link should have buffering of 
at least 4x MSS".

The point you raise is that the rule-of-thumb we discussed in the last mail 
does not work on slow links. Thus, I propose the following modification:

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 excluding the link layer RTT" + "link layer RTT")
x link speed.

>Otherwise, the limit must be shared by all flows.

I agree. In that case, one might need to have some idea of the average 
number of concurrent flows sharing the link.

///Reiner