Re: [conex] byte vs packet counting

[John Leslie <[e-mail]>]

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.

   I do understand that both of these folks think they understand the
mathematical issues involved better than the rest of us. They may well
be right.

   But this is an IETF Working Group, not an academic paper review
board. I'm not interested in arguing mathematics -- I believe we need
to discuss how to get a protocol which enough operators will implement.
And I'm interested in arguments of what will harm our chances of
widespread implementation.

> I think we're both now agreeing that the /goal/ should be 
> byte-balance for ConEx auditing. Correct?

   Hopefully it's no surpprise to anyone that _I_ don't agree.

> I am also in full agreement that this goal isn't always easy to meet 
> if retrofitting ConEx onto an existing transport like TCP. It works 
> if the packet sizes are regular, but if they are lumpy, the sender is 
> likely to understate or overstate.

   I can agree with that. (It seems to me that that's a potential
barrier to implementation.)

> And I agree that these aren't necessarily just corner-cases (well, I
> guess there is a large set of cases with regular packet sizes, but
> the corner is also quite large).

   Again, I agree.

> You ask what I think we should do about this. My view, we should:
> a) state what the goal should be for all transports (byte-balance)
> b) give advice on how to implement a TCP sender to do as well as it can
> c) run experiments and see whether the outcome is good enough, or if 
> further protocol mechanism is needed.

a) I see no benefit in _merely_ stating a goal: if indeed the goal is
   worthwhile (of which I remain unconvinced), we need to justify the
   additional effort which may be required to meet it.

b) I see danger (not benefit) from asking implementors to do much in
   the way of modifications to TCP. I believe our goal is unattainable
   unless we can demonstrate benefit for flows where no TCP modifications
   are needed. (Our charter clearly allows for modification to the
   _receiver_ TCP implementations; but we should promote that, if at
   all, as an _additional_ benefit of ConEx with receiver modifications.)

c) I have _no_ problem with running experiments with sender modifications
   to see if there _is_ a benefit from byte-balance. My problem is with
   jawboning about the abstruse benefits of byte-balance in our _initial_
   documents.

> Concerning (b) advice on the best that TCP implementations can do:
> - the TCP receiver (if optionally supporting ConEx) should suppress 
>   ACK delay whenever it detects congestion and instead give immediate
>   feedback
> - TCP sender can use ack sequence numbers to improve its guess of the 
>   required size of an re-echo-loss or re-echo-ECN
> - If the receiver is not ConEx-aware, a sender that knows it is 
>   sending lumpy packet sizes can introduce additional credit to cover 
>   any mistakes.

- I support anything to encourage a faster feedback loop for reacting
  to congestion signals. I only suggest that asking for any particular
  changes to TCP _at_this_point_ may be counterproductive.

- I believe that what a modified TCP sender might do in reaction to
  congestion should follow from widespread experimental experience.

- I have a problem with asking a sender to _guess_ at what ConEx signal
  is needed in response to a congestion event.

> If a ConEx sender does unintentionally understate bytes of 
> congestion, the auditor will discard some packets, then the sender 
> will redress the balance with some more re-echo-loss and it should 
> all heal itself, albeit having suffered some losses in the process.

   IMHO, we're not ready to prescribe any particular _policing_ actions.
"Auditor" to me means a point of collection of information, not a point
of enforcement.

   Enforcement, to me, is premature in our primary documents now being
LastCalled. No doubt Bob feels confident he can prescribe enforcement
actions which are mathematically correct. Perhaps he can.

   But to me, describing _any_ policing at this time is dangerous.
Folks _will_ implement policing according to their _own_ interpretation
of the information available -- not necessarily the way we describe. :^(

> Do you think this is sufficient (at least to run experiments to test 
> whether it is)?

   I think we would do well to run experiments an that basis.

   (I do not think we should publish initial documents claiming the
"rightness" of what such experiments seek to confirm.)

--
John Leslie <[e-mail]>