RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

> -----Original Message-----
> From: John Heffner [mailto:jheffner@psc.edu] 
> Sent: Wednesday, February 21, 2007 3:20 PM
> To: tcpm@ietf.org
> Cc: Anantha Ramaiah (ananth); Michael Welzl; toby.moncaster@bt.com
> Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00
> 
> Anantha Ramaiah (ananth) wrote:
> >  
> > 
> >> is at odds with RFC 2581, which says:
> >>
> >>> Out-of-order data segments SHOULD be acknowledged immediately, in 
> >>> order to accelerate loss recovery.
> >> ...although I wonder why this is only a SHOULD, and not a 
> MUST, and 
> >> herewith suggest to change this in 2581bis, unless there's a good 
> >> reason not to do so.
> > 
> > Although the RFC says SHOULD, in reality it is treated as a MUST, I 
> > think the majority of stacks will send a ack for a 
> out-of-order segment.
> > It probably makes sense to make this a MUST in RFC 2581bis 
> if we want 
> > to enforce some basic congestion control stuff like 
> > fast-retransmissions (which is worded as a MUST by the way).
> > 
> > The only reason which I can think off why it was worded as a SHOULD 
> > instead of a MUST is when the basic cong.control on TCP was written 
> > long time back, "putting" many packets (even if they serve 
> some useful
> > purpose) was probably considered aggressive, in the current context 
> > pure ACK's. I am sure there are folks in the list who may 
> have better 
> > answers.
> > 
> > OTOH, recently, we were discussing about rate-limiting the no. of 
> > duplicate ACK's from mis-behaving receivers in the context of RFC 
> > 2581bis, now there is a mention about
> > 
> "some-receivers-that-may-exist-who-don't-send-duplicate-acks-for-out-o
> > f-
> > order-segments-received" 
> 
> 
> I would be reluctant to change this to a MUST.  A few things 
> that come to mind:
> 
> 
> As you mention, some receivers might want to adopt a slightly 
> different 
> ACK strategy if there's persistent reordering, to avoid having to ACK 
> every packet in steady state, and to prevent triggering fast 
> retransmit 
> on senders that don't do NCR (RFC4653) or similar.

I am not aware of receivers that rate limit the ACK's due to the fact
that there was persistent re-ordering in the network. YMMV.

> 
> In CPU- or interrupt-bound senders, suddenly doubling the 
> rate of ACKs 
> it must process can have adverse effects on performance.  It

Well, I would classify this as the problem of the receiver which isn't
able to process these ACK's. So, if I understand what you are saying
correctly, if the peer to that receiver isn't sending a duplicate ACK
for every out-of-order packet received, things would work well in this
particular case, in cases if it peers with a box (host/router any TCP
device) which follws the SHOULD clause seriously and ack's every other
out-of-order-packet, then the receiver is in trouble? After all the
receiver can chose to drop the ACK, when it detects conditions that
effect performance. It is not rocket-sicence to implement performance
monitors and take corrective actions.

<snip>

> 
> Paths with severe asymmetry may want to thin ACKs.  There were some 
> papers on this in the mid to late 90's coming out of work with 
> satellites and ADSL.

Ok.

> 
> There's been some talk lately about reverse path congestion control. 
> (This would be much harder with TCP than DCCP, but maybe someone can 
> figure it out?)

By reverse path, you mean ACK congestion control? Data transfer can be
bi-directional.

> 
> 
> Some of this stuff might be hair-brained or not, but we don't want to 
> restrict flexibility unless it's really necessary.

I agree. My point ( I haven't surveyed the whole internet/intranets
obviously) is :-

- since it is believed that most of the stacks existing today, ACKs
every out-of-order segment it received, "SHOULD" clause has been in the
experimental stage for a while..

- The internet has changed a long way what it was 20+ years back when
the original TCP specs were written and some of the assumptions that
were made are no longer commonplace. In other words the assumptions
which were common has become rare today.

Hence my thinking ( I know some folks wouldn't like it) is we don't lose
much by changing it. May be we don't lose much by not changing ( except
that we would be in a situation of not refelecting the common practice
in the standards) as well :-)

-Anantha

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm