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

[Gorry Fairhurst <[e-mail]>]

Lloyd Wood wrote:
> 
> On Tue, 6 Nov 2001, Reiner Ludwig wrote:
> 
> > attached, please, find an update of section 4. Thanks to comments from Mark
> > and Gabriel.
> >
> > Comments to this list are welcome!
> 
> 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.

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.

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

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

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

> 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.
> 
> <[e-mail]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>