Re: [conex] Accounting of ConEx signals

[John Leslie <[e-mail]>]

Mirja K?hlewind <[e-mail]> wrote:
> 
> Richard and I are currently working on the TCP modifications draft.
> And we get always stocked at the same question how the accounting
> of the ConEx signal should be done. I believe we assume that the
> ConEx signal is counted byte-wise that means all bytes of a marked
> packet are assumed to expose the link congestion.

   Marcello may well believe this needs an "official" answer; I am
not convinced it does.

   From an ISP standpoint, short packets don't necessarily contribute
less to congestion. And IMHO, the most important signal of ConEx is
that the sender is sending this packet despite a belief it may
contribute to congestion.

   Whether the initial upstream counts marked packets as per-byte,
per-packet, or somewhere in between doesn't seem to me to be helpful
for us to define at this stage.

> First of all, I have to say hat this is nowhere officially defined.
> That lead to the following couple of questions:
> 
> 1. Where do we need to define this? In the IPv6 doc? 

   I don't believe we need to define it -- we're likely better to
define it _after_ some consensus appears.

> Because it might be a more general question and it must be clear
> to everyone that if we account the signal byte-wise this has to be
> done in the endsystem as well as in every network device using
> this information.

   That's not clear to me...

> 2. Which bytes of a packet do we take? The IP length incl header,
> the IP payload incl. TCP header or the actual payload?

   If we were to define this, we'd have to aim for bits-on-the-wire
plus some estimate of packet overhead.

   (IMHO, bits-on-the-wire isn't always clear to the sender.)

> In TCP if a packet get lost (with SACK) we only know how many
> payload got lost. We do not know the number of packets/headers
> that were used to transmit this data. If we would lose one big
> packet and then retransmit a large number of small packets instead
> (which are all ConEx marked) that might give quite a different
> ConEx signal.

   (That's not an unreasonable case.)

> On the other hand, what causes the congestion is the whole packet
> incl header(s). What is the right thing to do?

   I'd punt...

   For most purposes, I think just counting the marks will suffice;
but clearly we shouldn't prohibit experiments counting something else.

--
John Leslie <[e-mail]>