Subject: Re: [conex] Comments on ConEx TCP Modifications

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Apr 2012 13:23:02 +0200

Hi Richard, hi Bob,

my concern with a policy that drops (only) marked packets is, that the 
congestion exposure signal get corrupted and thus the audit will see too 
little ConEx markings and thus might drop additional packets. In the 
simulation this was no problem as there was not audit.

Should we add somewhere a recommendation that ConEx marked packets should 
preferably be not dropped (if another packet is available to drop) as those 
packets carry additional information?

Mirja

On Saturday 31 March 2012 19:56:45 Scheffenegger, Richard wrote:
> Hi Bob,
>
>
> Richard Scheffenegger
>
> > I imagine people will design policers to try not to be firm but not
> > pathological to typical transport *responses* to loss, but I don't see
> > how ConEx-marking behaviour will matter to a policer.
> >
> > What are you thinking of here?
> >
> >
> > 1/ 'Best' treatment of L-markings
> > I have always been worried that dropping L packets could lead to
> > problems, by creating a "black hole", as follows:
> > 1) Bucket is empty, which must have been due to too many L packets.
> > 2) Policer drop causes sender to slow-down but also insert more L
> > packets. 3) Bucket empties faster.
> > 4) Goto 2)
> >
> > I suspected this might cause the sender to stall, so we always tried to
> > avoid dropping L-marked packets. I was interested to see that this didn't
> > happen in Alfons/Michael's simulations, so I would like to know the
> > details of their policer algo.
>
> In our current draft, we have effectively a SHOULD to set the L bit not
> with the retransmission itself, but with the next following (data) packet -
> at least the text can be interpreted that way. The intention was actually
> to prevent the interpretation of  L-bit == retransmission. But if the WG
> feels that explicitly marking only the actual retransmissions with L, to
> allow additional uses of the conex bits, we should spell that out more
> clearly:
>
> "When a
>    data segment is retransmitted, LEG will be increased by the size of
>    the TCP payload packet containing the retransmission, assuming equal
>    sized segments such that the retransmitted packet will have the same
>    number of header as the original ones.  When sending subsequent
>    segments, the ConEx L bit is set as long as LEG is positive, and LEG
>    is decreased by the size of the sent TCP payload with the ConEx L bit
>    set."
>
>
> However, I think you have one assumption in your 4 steps above that doesn't
> hold. The statement "bucket empties faster". I was under the impression,
> that the refill ratio of the buckts is time- and packet-rate invariant,
> not? With other words, within a given time t, the bucket fills up with b
> credits; if the packet rate during t, with conex marks exceeds b, the
> policer drops; this causes the sender to reduce the packet rate - so in a
> given time period t, fewer packets are seen by the policier (unless the
> sender is not reactive, of course). Even when all packets sent by the
> sender are marked with conex bits, eventually the packet rate will drop
> below b/t, and the policer won't drop any more packets...
>
> Or am I missing something there?
>
>
> But my issue is with the probability of dropping a packet; when the
> retransmitted data packets are dropped with a higher likelihood (and this
> depends on which packets carry the L-bit, and if the way the policer
> implements a "variable" drop probability depending on the conex marks),
> this may result in a higher probability of a retransmission get dropped,
> which will inevitably lead to a RTO stall of the TCP session... Which IMHO
> is undesirable (loss of ACK clock, significant latency etc).
>
> For that reason, I believe we must have understanding which packets should
> carry the L-bits (only retransmissions, regular data and retransmissions),
> and if packets carrying conex marks should be treated any different from
> packets being merely conex-enabled...
>
>
> Best regards,
>    Richard Scheffenegger
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 2 Apr 2012 20:40:50 +0000

Also a very valid concern!

If there is a preferential treatment to either type of packets (conex-marked or conex-enabled), retransmissions from TCP should be put in the category that is less likely to be dropped. I believe the reason for the current text around L-marks was to avoid the notion of L-Mark == Retransmission. However, explicitly exposing retransmissions may not be such a bad idea after all, thinking further about this... But that would imply that conex-marked packets get dropped with the same or lower probability as conex-enabled packets.

Nevertheless, avoiding slightly increased drop probabilities (vs. overall drop probability) for retransmissions is a more important aspect from the TCP point of view... However we achieve that; treating all packets equal would be good enough (equal to current state of affairs).

If retransmissions are dropped with lower probability, that should statistically noticeable in lower total RTOs.

Best regards, 

Richard Scheffenegger

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Montag, 02. April 2012 13:23
> To: [email-masked]
> Cc: Scheffenegger, Richard; Bob Briscoe
> Subject: Re: [conex] Comments on ConEx TCP Modifications
> 
> Hi Richard, hi Bob,
> 
> congestion exposure signal get corrupted and thus the audit will see too little
> ConEx markings and thus might drop additional packets. In the simulation this
> was no problem as there was not audit.
> 
> Should we add somewhere a recommendation that ConEx marked packets
> should preferably be not dropped (if another packet is available to drop) as
> those packets carry additional information?
> 
> Mirja
> 
> 
> > > pathological to typical transport *responses* to loss, but I don't
> > > see how ConEx-marking behaviour will matter to a policer.
> > >
> > > I suspected this might cause the sender to stall, so we always tried
> > > to avoid dropping L-marked packets. I was interested to see that
> > > this didn't happen in Alfons/Michael's simulations, so I would like
> > > to know the details of their policer algo.
> >
> > In our current draft, we have effectively a SHOULD to set the L bit
> > not with the retransmission itself, but with the next following (data)
> > packet - at least the text can be interpreted that way. The intention
> > was actually to prevent the interpretation of  L-bit ==
> > retransmission. But if the WG feels that explicitly marking only the
> > actual retransmissions with L, to allow additional uses of the conex
> > bits, we should spell that out more
> > clearly:
> >
> > "When a
> > However, I think you have one assumption in your 4 steps above that
> > doesn't hold. The statement "bucket empties faster". I was under the
> > impression, that the refill ratio of the buckts is time- and
> > packet-rate invariant, not? With other words, within a given time t,
> > the bucket fills up with b credits; if the packet rate during t, with
> > conex marks exceeds b, the policer drops; this causes the sender to
> > reduce the packet rate - so in a given time period t, fewer packets
> > are seen by the policier (unless the sender is not reactive, of
> > course). Even when all packets sent by the sender are marked with
> > conex bits, eventually the packet rate will drop below b/t, and the policer
> won't drop any more packets...
> >
> > retransmitted data packets are dropped with a higher likelihood (and
> > this depends on which packets carry the L-bit, and if the way the
> > policer implements a "variable" drop probability depending on the
> > conex marks), this may result in a higher probability of a
> > retransmission get dropped, which will inevitably lead to a RTO stall
> > of the TCP session... Which IMHO is undesirable (loss of ACK clock,
> significant latency etc).
> >
> > For that reason, I believe we must have understanding which packets
> > should carry the L-bits (only retransmissions, regular data and
> > retransmissions), and if packets carrying conex marks should be
> > treated any different from packets being merely conex-enabled...
> >
> >
> > Best regards,
> >    Richard Scheffenegger
> >
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: +49(0)711/685-67973