Re: [conex] byte vs packet counting

[John Leslie <[e-mail]>]

Matt Mathis <[e-mail]> wrote:
> 
> Bob and I prefer to argue in private, because it works better.

   The IETF way, alas, is to argue in public. We need to learn how to
do so without overly harming our ability to work together.

> We always assume that the other person is correct, and make every
> effort to try to understand what they think and why. This is why we
> have often been able to clearly restate each others arguments.

   A decidedly useful practice.

   Alas, I seem to have no luck restating Bob's arguments. He reminds
me a bit of John Campbell of "Analog" fame, of whom it was frequently
said, "if he finds you're agreeing, he changes the subject!"

> What typically happens is that we discover some hidden assumption,
> and that both of our initial positions are over simplifications and
> at some level both are wrong.

   Congratulations!

   I'm more than willing to both be wrong. ;^)

> When we argue in public, the entire discussion get rat holed about
> details that are aren't on the table, either because the rest of us
> already have consensus or they just are not important at this stage.

   Consensus isn't something for "the rest of us" to have.

   In the IETF, we talk of "rough consensus". That doesn't mean that
some of us deserve to be ignored: it means that some of us agree to
"be in the rough" and stop arguing an issue.

   As for "important at this stage", I'm afraid none of us are
omniscient enough to know what's important.

   There is, however, a time when folks are "ready to learn" and a
much larger time when they aren't. :^(

   But IMHO they only deceive themselves when they say "it's not
important" instead of "I'm not ready".

   But I digress...

> My take away from the intended discussion with Bob is that
> -abstract-mech- is flawed in that it is entirely too casual about
> units.

   I'd be happy to work on what the "units" should be.

> The units (primarily bits v bytes v packets of congestion) should
> be an explicitly chosen parameter for each span of the model
> (congested router to receiver, ACKs carrying the signal back to
> the sender, reinserted feedback from the sender to the audit
> and policy functions).

   That sounds difficult...

> While I am inclined to agree with Bob that the congestion signal
> should be in bytes,

   (I'm less inclined...)

> I am less convinced that it is ok for the ACKs to only carry
> segment counts.  I am willing to proceed on the basis of his
> assumptions, however it is critical that we all understand that
> this is a design decision that might be changed in the future if
> there is a compelling reason to do so.

   I understand _that_ Bob believes counting bytes is more correct
than counting packets, but I don't understand why he believes it.
I see folks responding to his repeated claims with, "But it's
not the case for this common situation;" and there the thread dies.

   Elsewhere, I read of concerns that "small packets shouldn't be
penalized for being small," but I don't know if that's Bob's
argument.

   Whether or not it is, I find it unconvincing. If small packets
were _actually_ being significantly punished for being small, the
sender would find a way to enlarge them. I simply don't see that
in the wild.

   And that argument seems to really be, "Look how nice I'm being
by sending smaller packets! Why don't folks reward me more?"

   (I can think of a half-dozen reasons, which I won't list.)

   In practice, the folks who do send lots of small packets want
to see less jitter in RTT. But it's the large packets which
usually cause the jitter. Alas, the medium is shared...

> The abstract mech doc needs to state that proposed signal mappings
> for a given tentative encoding must be explicit about units.

   That sounds like an improvement...

> It is also important to note that for legacy interoperability
> using a sender only implementation, we can not assert different
> algorithms than are present in current network devices and ECN
> enabled receivers.

   I agree these, in practice, are unknowable. :^(

> My example earlier in the thread illustrates a rather extreme
> pathological case where bytes v segments might change sender
> behavior. In the common case and as a natural approximation,
> the sender will probably assume that the data in not lumpy, and
> that reflecting the correct number packets is good enough.

   It strikes me as seriously sub-optimal to say, "It's reasonable
to assume X" and at the same time, "It's more correct to punish
anyone who assumes X".

   I frankly don't see why abstract-mech needs to say either of
these. We should perhaps state that experiments may include
scenarios where some nodes may punish X while other nodes may
punish Y; but I'm very uncomfortable with suggesting that either
of those punishments is "correct".

> Clearly when all of the packets in a given connection have uniform
> sizes, it doesn't matter to any component, except the policy devices.

   I think we have agreement there...

> The places proper treatment of lumpy data might matter are the
> policy and audit devices, which will be the last part of ConEx to
> have fully bound specifications.

   Agreed.

> Some of their details are even explicitly out of our scope,
> although we do have to demonstrate the existence of algorithms that
> provide useful signals.

   Algorithms, plural, yes.

> As I reflect on the broader debate, it is clear to me that we
> really need to understand choosing units of congestion as an
> engineering compromise.

   Perhaps even an engineering compromise where different senders
and receivers make different trade-offs?

> Like all such compromises, it has to balance the costs of
> difficulty of implementation vs opportunity cost of reduced
> precision.

   Agreed.

> Furthermore, extended debate without hard data is pointless.
> It just doesn't matter at this stage. We can accept Bob's assumption
> for the time being, note that it is "provisional" and revisit it
> later, if or when we encounter a problem that would be better
> solved with different assumptions.

   Remember the Tao of Internet: "We reject kings, presidents, and
voting..." I don't remember electing Bob as President; nor do I
see good reason to accept him as King. What other reason is there
to accept Bob's assumption when we have so much reason te believe
it is incomplete or worse?

> John, can we arrange a phone call some time?

   (Matt and I have talked at some length on the phone. I like to
believe I have a better understanding of research in this field
because of this. I just don't read the research the same way Bob
does...)

--
John Leslie <[e-mail]>