Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Jun 2000 15:21:54 -0400

I agree that small packets are not necessarily evil, and that test results
would be quite interesting to see.

What I was doing, though, was to assume _either_ a high probability of small
packet dropping _or_ a high probability of large packet dropping. And, with
the correction Lloyd made, I concluded that TCP would always be penalized in
cases of congestion.

If small packets are evil, it follows that ACK packets will be dropped, so
TCP will go through retries. Bad news for TCP.

If large packets are dropped, then TCP sessions which always use large
packets (e.g. FTP) will suffer. But TCP sessions which use small packets,
such as TELNET of even HTTP, can see a cliff effect.

Let's just suppose that some small packets get dropped in a congested
period, in spite of their preferential treatment. Now the TCP source, which
will retry transmitting packets, will have enough backed up data to go out
that its data packet size will have increased (TCP makes no attempt to keep
a particular packet size, unless MTU is reached). So the large retried data
packets will be _less_ likely to succeed than the original packets were. The
more the congestion, the more likely TCP is to fail, with this strategy.

A very interesting strategy to diddle around with.

Bert
[email-masked]

> -----Original Message-----
> From: Kathleen Nichols [mailto:[email-masked]]
> 
> I'm with Lloyd here: there's no reason to assume that
> small packets are inherently evil and should be dropped.
> (Just as this is also true of UDP packets.)
> And some experimentation has us believing it's best
> to to just "count packets" regardless of size when it
> comes to implementing drop probabilities.
> 
> Lloyd Wood wrote:
> > 
> > On Thu, 15 Jun 2000, Manfredi, Albert E wrote:
> > 
> > > > -----Original Message-----
> > > > From: Andrew Smith [mailto:[email-masked]]
> > >
> > > > As an aside, I don't think we've discussed this here (and it
> > > > has nothing to
> > > > do with this consensus stuff) but I wonder how a RED dropper
> > > > that factors in
> > > > the size of the packet when determining its drop probability
> > > > would behave -
> > > > do any of the studies discuss this?
> > >
> > > Interesting notion. Just words here:
> > >
> > > If the strategy were to give small packets a higher drop 
> probability, then
> > > TCP become slow but remain successful. Any small packets 
> would be dropped,
> > > so the TCP source would soon be generating mostly large packets.
> > 
> > I don't follow this.
> > 
> > TCP acks are small, so they're at a disadvantage here.
> > 
> > telnet packets will suffer, packets at the path MTU size 
> can't be made
> > any larger, and where's the algorithm in TCP that says 'I'm
> > experiencing congestion, so I'll try sending larger packets to get
> > around it'? We already have path MTU discovery to reduce 
> the number of
> > packets from the start.
> > 
> > L.
> > 
> > 
> > > At the same time, UDP streams using small packets would 
> show lots of
> > > dropouts.
> > >
> > > If the opposite strategy were implemented, then if things 
> got congested and
> > > TCP sessions became backup up, TCP would soon quit 
> completely. On the other
> > > hand, UDP flows would be very good, low jitter, low latency.
> > >
> > > Bert
> > > [email-masked]
> > 
> > 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Nirav Dagli <[email-masked]>
Date: Thu, 15 Jun 2000 13:15:04 -0700

dropping ACK packets will result in re-transmits of wastage of bandwidth
-
doesn't help the "congestion".  but this doesn't apply to ALL small
packets.  Best is to make sure the ACKs go out with a difference DSCP
and
have a different drop algroithm applied; and keep the drop algorithm
itself independent of pkt sizes to be fair to all applications.

nirav

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 15 Jun 2000 14:15:53 -0700

Nirav Dagli wrote:
.. Best is to make sure the ACKs go out with a difference DSCP

I think Nirav has captured the essence of diffserv: if you
want a particular treatment, mark the packet for it. This
is explicit and saves us from making values judgements 
implicitly tied to some property or another of a packet.
Exercises in the latter are possible, but they aren't diffserv.

	Kathie

---

From: stanislav shalunov <[email-masked]>
Date: 15 Jun 2000 12:32:37 -0400

> more the congestion, the more likely TCP is to fail, with this strategy.

If small packets are treated as evil and have greater loss
probability, data aggregation would be greatly encouraged.

However, for TCP that would mean that the network, instead of
delivering small ACK packets, elects to deliver large data
retransmission packets.  It seems it would be better to deliver
smaller ACK packets and be done with it.

This suggests making drop probability a product of some factor and the
number of bytes in a packet.

On the other hand, it seems that rewards for data aggregation are a
good thing to do, so slower than linearly growing function might work
better.  Drop probability need not decrease to encourage data
aggregation:  If the function is concave up, then it would guarantee
that splitting data packets (presumably to obtain better treatment
reserved for small packets) is not profitable.

If product of a factor (that depends on packet marking, etc.) and
something like square root of packet size were used, would that make
sense?

It seems it would both encourage data aggregation, but give smaller
packets slightly preferential treatment (so ACKs in TCP--or anywhere
else are delivered with better probability than data).

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 16 Jun 2000 14:41:05 +0100 (BST)

On Thu, 15 Jun 2000, Kathleen Nichols wrote:

> want a particular treatment, mark the packet for it.

This doesn't help piggybacked acks in any way, and means that TCP's
ack stream is now being treated in two different ways...

> This is explicit and saves us from making values judgements 

The property of a packet as far as TCP acks are concerned now becomes
a 'well, is there a payload as well?' value judgement.

(setting DSCP depending on the ACK flag state adds interesting
problems as piggybacked acks get through and other data doesn't -
dupacks, invoking fast recovery, etc - and can really only be done at
the endhost.)

> Exercises in the latter are possible, but they aren't diffserv.

The essence of TCP doesn't map well to diffserv. If you consider how
TCP performs in highly asymmetric conditions, you can see why giving
acks a higher drop precedence could be a bad idea.

TCP presumes symmetry in a number of ways (consider RTT and
self-clocking); to me that symmetry suggests that you start out
with the assumption of one DSCP assigned to all the packets of a TCP
flow, be they data/acks/both. They're all related.

[Note: this is NOT one DSCP/drop precedence for all TCP traffic and
 one DSCP/drop precedence for all UDP traffic, which is just nutty.]

I suppose someone will hack up some horrific spoofing gateway
unbundling piggybacked acks for entry to diffserv networks managed by
the insanely picky...

L.

diffserv needs a reworked TCP to exploit available granularity, if you
ask me.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 19 Jun 2000 15:15:01 +0100 (BST)

Bad form to follow myself up, but:

> ack stream is now being treated in two different ways...

After a bit of thought, I've decided both are naive approaches.

Better (albeit more complex) would be to cycle through a range of
treatments for the ACK stream; have a TCP receiver send out ACKs
regularly (i.e. no holding off response due to delayed acks).

Have varying treatment of the ACK stream in the diffserv network
reinvent the concept of delayed acks (acks marked at the 'top' part of
every cycle should be likely to get through if others are dropped).
You should then be able to drop some acks with some degree of control
and without completely messing up TCP's self-clocking etc. Of course,
this assumes that all is well and the receiver window is advancing; if
not, you might want the receiver to be able to set/request a higher
DSCP for acks on ingress.

(piggybacked ACKs would be high priority since the payload should be
high priority; you should be able to be more tolerant of dropping the
odd ACK when you know there'll be another one along in a bit.)

L.