Subject: Re: [ledbat] ledbat Digest, Vol 30, Issue 10

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 29 Jun 2011 07:30:13 +0200

Hi

I believe it is OK to say that LEDBAT should work in a 3168-ish way to ECN marks. i.e in the same way that it reacts to loss and possibly just reference to RFC3168.

I don't fully agree with the sentence "there shouldn't occur any ECN marking (and of course no losses neither) as LEDBAT will reduce it's sending rate to basically zero before any queues overflow". 
For certain wireless access it is possible to tune ECN marking algorithm such that they trigger just at the bend on the hockey stick. Means that packets are ECN-CE marked even though the delay+jitter is quite moderate.
Of course this is pretty much dependent on the design of the ECN marking but I wouldn't rule out that packets are "LEDBAT packets" are ECN marked.

Regards
Ingemar  

> 
> Hi Gorry.
> 
> > Mirja seems to raise a valid point...
> >
> > I think it would be extremely good to encourage the use of ECN for 
> > such applications, by saying explicitly that ECN could 
> offer benefit 
> > when the infrastructure supports this. To allow this, a 
> LEDBAT session 
> > needs to send packets with ECT(x), and then MUST include 
> appropriate 
> > control functions.
> I don't think we should recommend for LEBDAT to be 
> ECN-capable because the selection of a congestion control 
> mechanism is, from my point of view, not related to the 
> question to support ECN or not.
> Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified 
> independent of any framing protocol (e.g. BitTorrent uses UDP).
> And when LEDBAT is working correctly, there shouldn't occur 
> any ECN marking (and of course no losses neither) as LEDBAT 
> will reduce it's sending rate to basically zero before any 
> queues overflow.
> 
> > - whatever, I think reception of an ECN mark MUST cause the 
> > corresponding sender to perform a congestion response - 
> i.e. can not 
> > be ignored.
> My only question was: Should we mention _explicit_ that 
> LEDBAT has to halve its window on an ECN mark or is it enough 
> if RCF3168 is defining this _implicit_ by saying (every) 
> congestion control should react in the same way to ECN marks 
> as it would to loss.
> In both cases a LEDBAT flow has to halve this window on an 
> ECN mark (as on loss). 
> 
> So in general, I'm not sure if we should talk about an TCP/IP 
> mechanism (ECN) in this draft when we only specify the 
> algorithm and not talking about anything TCP specific...?
> 
> Mirja
> 
> 
> ------------------------------
> 
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat
> 
> 
> End of ledbat Digest, Vol 30, Issue 10
> **************************************
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 29 Jun 2011 14:24:04 +0200

Hi Ingemar,

I did not very much investigations about LEDBAT in a wireless scenario. But 
LEDBAT is supposed to keep the extra delay at TARGET ms. Even if there is 
some other extra delay e.g. introduced by the wireless network, LEDBAT will 
try to keep TARGET ms extra delay on the link. I guess in a wireless scenario 
TARGET has to be chosen large enough thus.

But regarding marking or dropping: I guess you assume a scenario, where TARGET 
is chosen very large and the marking/dropping threshold is very small, and 
thus LEDBAT will get quite frequent marks/losses. In this scenario LEDBAT 
will fall back to normal TCP behavior (with a little slower increase). I do 
not consider this case as regular LEDBAT behavior, as you don't have the 
LEDBAT advantage anymore.

Mirja

On Wednesday 29 June 2011 07:30:13 Ingemar Johansson S wrote:
> Hi
>
> I believe it is OK to say that LEDBAT should work in a 3168-ish way to ECN
> marks. i.e in the same way that it reacts to loss and possibly just
> reference to RFC3168.
>
> I don't fully agree with the sentence "there shouldn't occur any ECN
> marking (and of course no losses neither) as LEDBAT will reduce it's
> sending rate to basically zero before any queues overflow". For certain
> wireless access it is possible to tune ECN marking algorithm such that they
> trigger just at the bend on the hockey stick. Means that packets are ECN-CE
> marked even though the delay+jitter is quite moderate. Of course this is
> pretty much dependent on the design of the ECN marking but I wouldn't rule
> out that packets are "LEDBAT packets" are ECN marked.
>
> Regards
> Ingemar
>
> > Hi Gorry.
> >

-- 
-------------------------------------------------------------------
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: Gorry Fairhurst <[email-masked]>
Date: Wed, 29 Jun 2011 17:46:30 +0100

Agree (see my email response).

Gorry