Re: [conex] byte vs packet counting

[Matt Mathis <[e-mail]>]

Rolling back this whole thread...

On Sun, Nov 20, 2011 at 1:40 PM, John Leslie <[e-mail]> wrote:

> Bob Briscoe <[e-mail]> wrote:
> >
> > Matt,
>
>    (I do understand that Bob is addressing Matt...)
>
> > [Adding the ConEx list back in]
>
>    I do not agree that this is a discussion which should gate on the
> opinions of Bob and Matt.
>

Bob and I prefer to argue in private, because it works better.   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.  In that process
comes enlightenment, deeper understanding and an opportunity to
tease apart our underlying assumptions.  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.

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.

My take away from the intended discussion with Bob is that -abstract-mech-
is flawed in that it is entirely too casual about units.  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).

While I am inclined to agree with Bob that the congestion signal should be
in bytes, 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.  The abstract mech doc needs to state that
proposed signal mappings for a given tentative encoding must be explicit
about units.

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.   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.
  Clearly when all of the packets in a given connection have uniform sizes,
it doesn't matter to any component, except the policy devices.

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.   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.

As I reflect on the broader debate, it is clear to me the we really need
to understand choosing  units of congestion as an engineering compromise.
 Like all such compromises, it has to balance the costs of difficulty of
implementation vs opportunity cost of reduced precision.   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.

John, can we arrange a phone call some time?  I want to understand your
vision for ConEx better.  Is the phone number on your 2017 consulting page
correct?  (New Hampshire)

Thanks,
--MM--