Subject: Re: draft-ietf-pilc-2.5g3g-04.txt

From: Reiner Ludwig <[email-masked]>
Date: Tue, 06 Nov 2001 14:23:17 +0100

Hi,

attached, please, find an update of section 4. Thanks to comments from Mark 
and Gabriel.

Comments to this list are welcome!

///Reiner

This section outlines additional mechanisms and parameter settings that may increase the end-to-end performance when running TCP across 2.5G/3G networks. Note, that apart from the discussion of the RTO's initial value, those mechanisms and parameter settings are not part of any standards track RFC at the time of writing, and can therefore not be recommended in general.

Link layer mechanisms for increasing TCP performance include enhanced TCP/IP header compression schemes [16], active queue management [15], link layer retransmission schemes [11], and holding on to packets during transient link outages [11]. Shortcomings of existing TCP/IP header compression schemes RFC1144 [35], RFC2507 [36] are that headers of handshaking packets (SYNs and FINs), and TCP option fields (e.g., SACK or timestamps) are not compressed. In fact, the presence of timestamps effectively disables header compression based on RFC1144. Although RFC3095 [34] does not yet address this issue, the ROHC working group is developing schemes to solve the mentioned shortcomings. Especially, if many short-lived TCP connections run across the link, the compression of the handshaking packets may greatly improve the overall header compression ratio. Implementing active queue management is attractive for a number of reasons as outlined in RFC2309 [15]. One important benefit for 2.5G/3G networks, is that it minimizes the amount of potentially stale data that may be queued in the network ("clicking from page to page" before the download of the previous page is complete). Avoiding the transmission of stale data across the 2.5G/3G radio link safes transmission (battery) power, and increases goodput (the ratio of useful data over total data transmitted). Another important benefit of active queue management for 2.5G/3G networks, is that it reduces the risk of a spurious timeout for the first data segment as outlined below.

Finding ways to avoid the round-trip times required for TCP's connection setup and disconnect is particularly attractive for 2.5G/3G networks since these networks are commonly characterized by high delays. This would be particularly beneficial for short-lived, transactional (request/response-style) TCP sessions that typically result from browsing the Web from a smart phone. However, existing solutions such as T/TCP RFC1644 [14], have not been adopted due to its security concerns [31].

Spurious timeouts, packet re-ordering, and packet duplication may reduce TCP's performance. Thus, making TCP more robust against those events is desirable. Solutions to this problem have been proposed [17], [26], [37], and standardization work within the IETF is ongoing at the time of writing. Those solutions include reversing congestion control state after such an event has been detected, and adapting the retransmission timer and duplicate acknowledgement threshold. The deployment of such solutions may be particularly beneficial when running TCP across wireless networks. This is since wireless access links may often be subject to handovers and resource preemption, or the mobile transmitter may traverse through a radio coverage hole. Such disrupting events may easily trigger a spurious timeout despite a conservative retransmission timer. Also, the mobility mechanisms of some wireless networks may cause packet duplication.

The algorithm for computing TCP's retransmission timer is specified in RFC2988 [32]. That standard specifies that the initial setting of the retransmission timeout value (RTO) must not be less than 3 seconds. This value might be too low when running TCP across 2.5G/3G networks. In addition to its high latencies, those networks may be run at bit rates of as low as about 10 kb/s which results in large transmission delays. In this case, the RTT for the first data segment may easily go beyond the initial retransmission timer setting of 3 seconds. This would then cause a spurious timeout for that segment. Hence, in such situations it may be advisable to set TCP's initial RTO to a value larger than 3 seconds. Furthermore, due to the potentially large transmissions delays, a TCP sender might choose to refrain from initializing its RTT estimators (SRTT and RTTVAR, see [32]) from the RTT measured for the SYN, but instead take the RTT measured for the first data segment.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 6 Nov 2001 14:26:42 +0000 (GMT)

Some comments on parts below:

> Implementing active queue management is attractive for a number of
> reasons as outlined in RFC2309 [15]. One important benefit for
> 2.5G/3G networks, is that it minimizes the amount of potentially
> stale data that may be queued in the network ("clicking from page to
> page" before the download of the previous page is complete).

This seems to confuse e.g. web proxy caching with active queue
management; what is suggested has nothing to do with RED etc. or even
management of link-layer queues as far as I can see.

Active queue management like RED can't discard packets for a TCP port
if e.g. a FIN for that flow is seen coming the other way, or even
discard acks deemed unnecessary; to do that involves content sniffing
and breaks layering, and is unlikely to fit well with router
architectures where egress queues and egress are very separate things.

What you seem to be suggesting is not impossible, with effort (rather
like NAT in that), but fragile and not active queue management either.
'Smart content switching networks' would seem to be the current
industry buzzword such stuff falls under - Cisco's NetFlow etc. Or a
very very smart stateful PPP implementation that can see and sniff 
both sent and received packets - but certainly not active link-head
queue management as described in RFC2309.

> Another important benefit of active queue management for 2.5G/3G
> networks, is that it reduces the risk of a spurious timeout for the
> first data segment as outlined below.

I'm not sure that applies to active queue management as I understand
it; again I suspect that what you are talking about is something
different, crossing the link layer and several upper layers. RED and
active queue management can be applied to IPSec and UDP flows. Can
this? ('first TCP data segment'?) If you mean active queue management
decreases/smooths overall per-flow queuing time and thus the risk of
exceeding 3-sec RTO, well okay - but aren't we supposed to be doing
this in a stateful track-both-ways PPP queue or somesuch?

> Finding ways to avoid the round-trip times required for TCP's
> connection setup and disconnect is particularly attractive for
> 2.5G/3G networks since these networks are commonly characterized by
> high delays. 

link latencies, yes? propagation delay is small for terrestrial
networks; it's everything else that makes it large. Worth describing
in detail, imo.

> This would be particularly beneficial for short-lived,
> transactional (request/response-style) TCP sessions that typically
> result from browsing the Web from a smart phone. However, existing
> solutions such as T/TCP RFC1644 [14], have not been adopted due to
> its security concerns [31].

HTTP/1.1 pipelining does a lot to decrease short-lived flows, too.
T/TCP isn't so much an existing solution (Windows T/TCP
implementations, anyone?) as a whole new set of problems.

The rest of the text looks okay. In general this needs to indicate
what layers it is trying to describe; some specific examples may help.

cheers,

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 06 Nov 2001 14:54:45 +0000

> architectures where egress queues and egress are very separate things.

If you are speaking of reducing the volume of ACK packets which are queued,
some potentially relevant techniques are suggested in....

http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-06.txt

Again, subject to be being able to implement this, by "seeing" TCP flows.

> networks; it's everything else that makes it large. Worth describing

Another phrase could be "link transit delay" - meaning total delay
incurred by sending over the link.

> implementations, anyone?) as a whole new set of problems.
Probably worth mentioning T/TCP anyway, it was talked about a lot,
even if it is not widely implemented.

A Congestion Manager (CM) may also help mitigate this...
ftp://ftp.isi.edu/in-notes/rfc3124.txt

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 06 Nov 2001 16:03:59 +0100

At 15:26 06.11.2001, Lloyd Wood wrote:
>management;

I don't think so. I suggest you look for some papers that discuss the 
problems of overbuffered, drop-on-full links. For example, you could check 
one of my own papers :-) 
http://iceberg.CS.Berkeley.EDU/papers/Ludwig-Sigmetrics99/index.html

>it;

At least it applies to AQM as others understand it: small queues = small 
queueing delay = less chance for a spurious timeout of the first data 
segment or even the SYN.

This was discussed at the last PILC meeting in London. I thought you were 
there.

>networks;

Fine. So let's replace "delays" by "latencies".

>it's everything else that makes it large. Worth describing
>in detail, imo.

Not imo.

>implementations, anyone?) as a whole new set of problems.

Sure HTTP/1.1 could be mentioned but this ID is about TCP stuff. Also, 
HTTP/1.1 doesn't help you much with many short-lived connections to many 
different hosts. Think of i-mode (WAP) services.

///Reiner

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 6 Nov 2001 16:55:21 +0000 (GMT)

> http://iceberg.CS.Berkeley.EDU/papers/Ludwig-Sigmetrics99/index.html

...which doesn't bother with the niceties of layering and presumes
that everything is visible at every layer. (I see you still agree with
yourself. Points for consistency, anyway.)

Can you give a better example of 'potentially stale data' that doesn't
bring web and layering into the mix? The text is imo misleading,
since AQM (as in RFC2309) will not actively seek to discard data,
since it doesn't _know_ that the data is stale. As far as I can see,
by 'potentially stale' you mean 'undelivered'.

An important benefit of AQM is that it brings fairness between
competing flows; being able to minimise _stale_ data queued is
actually a side-effect of this fair allocation, and is not
intentional. My point is that removing stale data from a flow is not a
deliberate AQM function, as your text seems to suggest with its
download example.

(I am reading what you have written. If what you are trying to say is
different...)

> >I'm not sure that applies to active queue management as I understand
[nice snip to score rhetoric points!]

> queueing delay = less chance for a spurious timeout of the first
> data segment or even the SYN.

er, you can have small drop-tail queues. Drop-tail queues aren't
considered to be AQM. So much for your syllogism.

> Fine. So let's replace "delays" by "latencies".

that sounds good.

> Sure HTTP/1.1 could be mentioned but this ID is about TCP stuff.

It is? Well, it mentions 'clicking' and 'browsing the web'. And unlike
T/TCP, HTTP/1.1 implementations exist, are used, and are increasingly
widespread.

> Also, HTTP/1.1 doesn't help you much with many short-lived
> connections to many different hosts. Think of i-mode (WAP)
> services.

i-mode != WAP. WAP != TCP, for that matter. Didn't you say that this
ID is about TCP stuff?

The short-lived connections problem is addressed by an intermediate
web proxy cache, of course. Then you only have a couple of long-lived
HTTP/1.1 connections from your user terminal over your wireless hop to
the proxy cache, which makes the intermittent short-lived connections
to different hosts over the fixed network. The long-lived HTTP/1.1
flows across the wireless hop can adjust well to the conditions of the
wireless subnetwork. A good network design will use web proxy caching
to address web performance problems.

And I see that grumbling about your understanding of proxy caching is
exactly where I started.

Is the draft going to discuss use of IPSec with TCP in detail? Much of
section 4 of the current -04 draft (open issues with header
compression) will conflict with IPSec; the existing security
considerations sentence:

  The use of a transport gateway as mentioned in Section 3.1.2
  introduces conflicts with IPsec; however TLS can be used in such
  architectures.

is confusing, since section 3.1.2 is currently 'large initial window'.
An editing oversight?

L.

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 07 Nov 2001 10:39:16 +0100

At 17:55 06.11.2001, Lloyd Wood wrote:
>bring web and layering into the mix?

Assume you have a ~10 kb/s modem. You have the choice between ISP_A that 
allocates 10 packets per modem in the modem pool or ISP_B that only 
allocates 3-4 packets per modem. Which ISP would you choose?

Imagine downloading a Web page across ISP_A and assume further that your 
modem link is the bottleneck. Half way through the download of that Web 
page you click the next link pointing to a different host. In the worst 
case you will have 10 packets sitting in the buffer in front of your modem 
link that have become stale with a 'click'. Depending on MTU, you will sit 
quite a while at your browser without anything happening. Further, your 
second TCP connection (let's also assume you don't have a proxy in the 
middle) might even get a timeout on the initial SYN due to the large 
queueing delay. Would you still choose ISP_A?

One could make the same example with the size of internal buffers of 
modems. Which modem would you buy?

Appropriately small buffers have nothing to do with layer violation or that 
"everything is visible at every layer". This you seem to confuse.

>competing flows;

That's one benefit. Other benefits are low end-to-end delays due smaller 
queues, *and* - this is were the "active" part comes in - to drop packets 
*before* the queue is full. This provide for extra room in your queue to be 
able to absorb packet bursts, to ensure that new flows are not locked out, etc.

The fairness is more a result of *random* dropping. You seem to confuse 
that AQM is *not* the same as RED. RED is only one way to implement AQM. An 
alternative would be to implement AQM, i.e., drop *before* the queue is 
full, but with a *deterministic* dropping policy. In fact, there are cases 
where the latter might make sense.

I suggest you read RFC2309 to see what AQM means.

>er, you can have small drop-tail queues.

That's a good point, and that would help to some extent. But then you have 
the problem that the queue will mostly be operated in the close-to-full 
state. As a result there is no (or often not enough) room to absorb bursts, 
say only two packets arriving back-to-back. This in turn results into poor 
performance of the many non-SACK TCPs that are still around.

So, I'm sure that you will be convinced by now that small queues and active 
dropping, i.e., AQM, is a good combination that is your TCP's friend. 
That's why it's mentioned in section 4 of this ID.

>i-mode != WAP.

They are similar in that i-mode and WAP2.X run ontop of TCP.

>WAP != TCP

That's only true for WAP1.X.

>Is the draft going to discuss use of IPSec with TCP in detail?

I don't think that we have to address IPsec issues in this ID. It should be 
clear to most readers that IPsec and IP-based header compression are no 
good friends.

///Reiner

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Thu, 8 Nov 2001 13:24:23 +0900

>   The use of a transport gateway as mentioned in Section 3.1.2
                                                     ~~~~~~~~~~~~~~~~~~~~
will be removed.
> is confusing, since section 3.1.2 is currently 'large initial window'.

Thanks. That is inconsistent with the other part.

Hiroshi  Inamura

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 8 Nov 2001 15:14:33 +0000 (GMT)

> >bring web and layering into the mix?

okay, you're restating the _same_ example.

> allocates 3-4 packets per modem. Which ISP would you choose?

it's all moot, since this sort of stuff isn't advertised, and it all
depends on use/experience, which brings a whole bunch of other things
into the mix. But still...

> link that have become stale with a 'click'. 

This presumes that my wireless device/computer/smart phone is only
generating a small number of flows related to web use and that those
ten buffered packet spaces can't be used productively for other
parallel flows (email, background ftp, telnet, whatever) that I'd
still like to take place without disruption.

> Depending on MTU, you will sit 
> quite a while at your browser without anything happening. 

big application and user assumptions there.

> Further, your second TCP connection (let's also assume you don't
> have a proxy in the middle)

Why? Any good ISP will have a proxy. That makes a strawman of your
argument.

> might even get a timeout on the initial SYN due to the large 

yes, because I know that I can do more with more flows with its deep
buffers at the other end of the slow link in general, and I'm not
interested in special-case optimisations that don't reflect my
behaviour. Deeper buffers do offer the potential for better fairness;
they cope better with bursts, and random-drop strategies have more
to choose from and become fairer.

> modems. Which modem would you buy?

That's a different question, because the modem I use needs can be
closely-coupled to the state of my endhost, where smaller is better.
By removing proxy caches from the ISP you've moved any endhost state
away from their modem and removed the close coupling that would have
been a good argument for small buffers in the case of a couple of
persistent http connections to the cache across the slow wireless
bottleneck link.

(If I was using the modem as a gateway for a shared network, I'd go
for deeper buffers.)

I don't see why you're willing to argue for a couple of flows across
the net and presume they're web traffic and that nothing else takes
place, but against a couple of web traffic flows using a proxy cache,
which is much better for a many-flows-to-endhost situation across a
bottleneck wireless link where the endhost is doing other stuff too.

> "everything is visible at every layer". This you seem to confuse.

Your example has a large number of assumptions all the way up to user
behaviour. Assuming how a flow is used to bolster your
argument _is_ a layer violation. Never mind no. of flows.

> queues,

generally, smaller numbers of in-transit packets per flow, due to
fairness. (Yes, AQM drops before the queue is full to leave room to
absorb bursts - but the difference in overall queue length can be
marginal. Providing fairness, as the popular RED AQM example does, has 
much more of an effect on the maximum amount of in-transit data for
_each_ flow.)

> *and* - this is were the "active" part comes in - to drop packets 
> that AQM is *not* the same as RED. RED is only one way to implement AQM. 

A _very_ popular example, though.

> An alternative would be to implement AQM, i.e., drop *before* the
> queue is full, but with a *deterministic* dropping policy. In
> fact, there are cases where the latter might make sense.

such as? (you're going to talk about TOS bits again, right?)

> I suggest you read RFC2309 to see what AQM means.

bt,dt. have you?

> That's a good point, and that would help to some extent.

not really, since with drop-tail queues the fairness is lost, allowing
flows with faster feedback loops to dominate the shared paths, and 
*small* drop-tail queues have even less room to allow other flows
some space while coping badly with bursts.

Of course, this isn't a problem at the modem head end for web use - if
you're running a local web proxy with persistent connections, as I've
previously tried to discuss with you. Then the web applications has a
better response to the user than other (background?) flows whose paths
go across the internet as well...

Small drop-tail queues _can_ work well - with a very small number of
competing flows, or at high speeds relative to the flow speeds (the
core).

> But then you have 
> state. 

another reason for preferring deeper buffers and ISP_A. ISP_B's small
buffer will be operating in the close-to-full state, which is clearly
bad by your arguments.

> As a result there is no (or often not enough) room to absorb bursts, 

ah, my 'small drop-tail queues have even less room to allow fairness'
point, I see.

gosh, another reason for preferring deeper buffers and ISP_A. ISP_B
will perform badly with non-SACK TCPs, since it may not have enough
room to absorb bursts such as two packets arriving back-to-back.

You've got a capacity mismatch, you need a buffer to help deal with
it and use the link efficiently for traffic. bigger mismatch -> bigger
buffer.

> dropping, i.e., AQM, is a good combination that is your TCP's friend. 

not, alas, by your arguments. You're focused on an edge-use case (no
web proxy, only a couple of flows of web traffic), and thinking about
other scenarios raises problems with your arguments.

for AQM, smaller amounts of in-transit packets per flow due to
fairness acting against large bursts != small queues.

> That's only true for WAP1.X.

...which is widely deployed (note that I didn't say 'widely used').
Sheesh, if you're going to talk about WAP2.x you'll just have to stop
talking about non-SACK TCP...

> I don't think that we have to address IPsec issues in this ID. 

'Security considerations' sections are mandatory.

> It should be clear to most readers that IPsec and IP-based header
> compression are no good friends.

So the draft will advocate header compression because it suits, and
neglect IPSec because it doesn't?

My take in general is that it won't be clear to most readers that
header compression (or other things) does not play well with IPSec,
because advocates of header compression (or other things) have a
tendency to omit inconvenient discussion of IPSec.

I note that your cited
http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html
is a good example of this tendency. Lots of mentions of header
compression, but no mention of IPSec there; would have been
inconvenient, I guess (even though IPSec is one hell of an example of
'inefficient interactions with header compression' as described by
your abstract).

I know I won't have changed your mind one iota (you're nothing if not
consistent), but hey, it's been fun.

tschuess,

L.