RE: [tcpm] AW: RFC2581bis ooo acking WAS: New I-D posted :draft-moncaster-tcpm-rcv-cheat-00

Actually my thinking is a bit different here. If there is choice to
pick, and I was given that choice, I would go with MUST ;-) A few
comments inline ( I may be repeating myself here)..... 

<snip>

> 
> Zitat von Ethan Blanton <eblanton@cs.ohiou.edu>:
> 
> > [The "something" below being delaying a dup ACK for a 
> segment received  
> > out-of-order using delayed ACKs.]
> >
> > Michael Welzl spake unto us the following wisdom:
> > > Does it make sense to allow a receiver to do something 
> which has no 
> > > obvious benefit, but clearly leads to undesirable behavior?
> >
> > Yes, if it does not break the protocol.  The receiver may 
> have other 
> > concerns than absolute rapidity of throughput; for example, power 
> > savings, bandwidth conservation, local processing time, etc. etc.
> > This, in my mind, simply falls into the realm of dictating 
> > implementation details.  The point is that a receiver delaying that 
> > out-of-order ACK will still perform correctly with respect 
> to protocol 
> > semantics, it may just take a little bit longer.

- The question I would ask is: "Is fast retransmission considered a
MUST? Yes, according to RFC 2581. If so I would think the surrounding
mechanisms, esp the ones which has direct influence, which facilitate
the fast-retransmision, can also be considered for a MUST candidate,
like in this case the generation of Duplicate ACK's. 

- The above example on "power savings, b/w conservation etc.," can be
applied to, in theory, to any packet, not just the duplicate ACK's. I
may sound argumentative here, but my experience ( not theoretical,
coming from working on internet devices/stacks which use TCP) treats the
dupacks as a MUST. Also to my knowledge, I haven't heard of stacks which
don't send or delay ( the latter may be ok, like you point out above)
these duplicate ACKs and would be interested to know if any one of the
widely used stacks permit this either naturally or by means of knob. But
this is my opinion, OMMV.

Thanks,
-Anantha

<snip>

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