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

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

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> 
> 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.

Yes, you're right. Which means that under congested conditions, TCP would
suffer with any algorithm that considers packet size.

> 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'?

It naturally works that way. If you have a data stream being transmitted
over TCP, and it is having a hard time getting out (unreturned ACK packets),
the TCP packets will grow to MTU size. The source does not keep trying to
transmit small packets with TCP, if the network is not accepting the packets
right away.

> We already have path MTU discovery to reduce the number of
> packets from the start.

Not all TCP streams maximize packet size as a rule. That applies to FTP,
sure, but not to other protocols, necessarily.

Seems to me that if we include packet size in the drop probability decision,
TCP would work well only when the network is uncongested?

Bert
[email-masked]

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

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 15 Jun 2000 21:21:28 +0100 (BST)

> transmit small packets with TCP, if the network is not accepting the packets

I think you're assuming that all acks are dropped and that TCP
segments grow in size as data to send is accumulated in the window.

A chatty application will be waiting for responses (and not all acks
are piggybacked), and not adding new data; a non-chatty one (e.g. an
ftp bulk transfer) will be passing data to TCP far faster than TCP
will send it, and is likely to be near/at path MTU as a result. Vague
memory of dumps showing steep peaks at ACK size and ethernet MTU
size seems to bear this out.

I have trouble imagining a case where the TCP sending rate and the
application data-passing rate are within, say, less than an order of
magnitude to make this kind of growth in segment size possible.

(and I'm reeling at the thought of a parallel universe where TCP sends
short packets and doubles their length, rather than their number, as
the congestion window opens, until it hits MTU size, where it starts
doubling number instead.)

And if all acks aren't dropped, you'll be filling in the gaps with
segment sizes pretty much defined for TCP by what TCP sent previously.
(no way to send two small disjoint dropped segments together in one
packet.)

[other mail]
> I concluded that TCP would always be penalized in cases of
> congestion.

TCP's semi-open feedback loop is set to create congestion; TCP
generally does a good job of penalising itself while driving hardware
demand.

Processing a packet generally takes the same amount of time regardless
of the length of the packet; why discriminate on length when
maximising packet size maximises efficiency?

L.

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