Subject: Re: WG Review: Low Extra Delay Background Transport (ledbat)

From: Robert Elz <[email-masked]>
Date: Fri, 31 Oct 2008 15:45:30 +0700

Date:        Thu, 30 Oct 2008 15:02:30 -0700 (PDT)
    From:        IESG Secretary <[email-masked]>
    Message-ID:  <[email-masked]>

This looks like useful work to do, and to me, the charter mostly
looks fine, just one point.

The (proposed) charter says ...

  | * operate well in networks with FIFO queueing with drop-tail
  | discipline

which in itself is OK, but doesn't say anything about links that
don't have those characteristics.

For different queueing strategies, I doubt there'd be a problem, but
I might expect the charter to be explicit that for (what I will call here)
intelligent queueing (almost anything other than FIFO that's useful)
the resulting protocol from this group will at the very least be
easily distinguishable (without necessarily resorting to DiffServ
mechanisms) from regular traffic.  Of course, is the result is an
IP application protocol that is not TCP, that's not going to be
an issue, but if it is a different behaviour of TCP stacks for
background traffic, it might not be so easy for intermediate routers
to be able to separate the background traffic from other traffic.

Perhaps more difficult, I'm not sure, would be how well the protocol is
to function with random drop, or RED, instead of drop tail.  I'd hope
it would be "at least as well as drop-tail", but I'm not sure, and
the charter doesn't say.

kre

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Lars Eggert <[email-masked]>
Date: Fri, 31 Oct 2008 13:24:39 +0200

Hi,

> don't have those characteristics.

The charter actually talks about non-FIFO-droptail queues. Below is  
Bruce Davie's summary, which sums up the intent very nicely:

On 2008-10-24, at 23:35, ext Bruce Davie wrote:
>> * operate well in networks with FIFO queueing with drop-tail  
>> discipline,
>> * where available, use explicit congestion notification (ECN),  
>> active queue management (AQM), and/or end-to-end differentiated  
>> services (DiffServ).
>
> The first bullet says "deal with the world as it is"; the second  
> says "deal with the world as you wish it were"
>
> I think that is a very sensible approach.

> mechanisms) from regular traffic.

It could be easily distinguishable (for example, we could decide to  
use the LTBE DSCP for all packets), but it doesn't need to be. LEDBAT  
is doing an end-to-end algorithm that is intended to work without any  
router support. (If there is router support, it'd obviously be nice if  
it performed better in some way.)

>  Of course, is the result is an

Right, the intent is that the LEDBAT mechanism should work at least as  
well if some sort of network help is available than when there isn't.  
Maybe we should make that explicit.

Thanks for your comments,
Lars

---

From: Robert Elz <[email-masked]>
Date: Sat, 01 Nov 2008 04:17:55 +0700

Date:        Fri, 31 Oct 2008 13:24:39 +0200
    From:        Lars Eggert <[email-masked]>
    Message-ID:  <[email-masked]>

  | > The first bullet says "deal with the world as it is"; the second  
  | > says "deal with the world as you wish it were"
  | >
  | > I think that is a very sensible approach.

Well, yes, but only if you really believe that the first bullet is
"the world as it is".   As it mostly is, probably, but completely?

I'm just a little concerned about routers that currently classify packets
based upon protocol/address/port info (ignoring TOS/DSCP) and then
don't do FIFO queueing.   But aren't "as you wish it were" either.
I didn't see anything in the charter that covered that intermediate case.
I don't necessarily expect that everything would "just work" with
such a router, but I'd like to be assured that updating its classification
engine (ie: adding a few new rules) will do the right thing.

  | It could be easily distinguishable (for example, we could decide to  
  | use the LTBE DSCP for all packets), but it doesn't need to be. LEDBAT  
  | is doing an end-to-end algorithm that is intended to work without any  
  | router support.

Yes, I understood that - what I'm concerned about is not (completely)
breaking routers that are currently trying to do something better than
nothing (where "breaking" means having background traffic given higher
priority than any other traffic.)

  | Right, the intent is that the LEDBAT mechanism should work at least as  
  | well if some sort of network help is available than when there isn't.  
  | Maybe we should make that explicit.

That is exactly what I was suggesting.

kre