[tcpm] Follow-up from AccECN discussion today: Robustness Principle

[Bob Briscoe <[e-mail]>]

Jonathan,

You said slide #9 was contrary to the Robustness Principle.
https://datatracker.ietf.org/meeting/113/materials/slides-113-tcpm-draft-ietf-tcpm-accurate-ecn-18-00#page=9 
and pasted at the end.
(I couldn't find the email you referred to about this, so apologies for 
starting a new thread).

There's a superficial resemblance, but the context is different.
The context of the robustness principle is the possibility of differing 
interpretations. Quoting from its source [RFC791]:

   While the goal of this specification is to be explicit
   about the protocol there is the possibility of differing
   interpretations.  In general, an implementation must be conservative
   in its sending behavior, and liberal in its receiving behavior.


In contrast, the advice in the AccECN draft is not about any possibility 
of differing interpretations.
Rather, it's a question of which is preferable:
* not even sending information,
* or ignoring it on receipt.

Both are ways of communicating nothing.

This is not question of handling ambiguity, given different ways of 
communicating nothing are all equally unambiguous (!)
This is rather a question of incremental deployment strategy.

_________
Unfortunately this intervention distracted from the point at hand, so 
I'll repeat it here:
* Given it's simple to implement the side that sends the AccECN TCP 
option, please do so;
* Then whenever anyone implements the side that receives it, they will 
have instant gratification.

Regards



Bob


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Switch round preferred partial implementation of AccECN Option?
     * Current:
         Even if a developer does not implement sending of the AccECN 
Option, it is RECOMMENDED that they still implement logic to receive and 
understand any AccECN Options sent by remote peers.
     * Proposed:
         Even if a developer does not implement logic to understand 
received AccECN Options, it is RECOMMENDED that they still implement 
logic to send AccECN Options to provide richer feedback to those remote 
peers that do understand it.
     * Reasons:
         1) Originally believed that Data Receiver (which sends AccECN 
Options) would be the more complex side, but it's the simpler
         2) TCP Option needed more in upstream where ACK filtering is 
greatest
         3) Servers more likely to be Linux where TCP option already 
fully implemented; client OS's still to be implemented
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\






-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/