Subject: Re: [conex] comments on draft-moncaster-conex-concepts-uses-01.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 15 Sep 2010 07:38:03 +0100

> From: Kevin Mason [mailto:[email-masked]] 
> Sent: Mittwoch, 25. August 2010 01:30
> >    ConEx clearly can be useful for distinguishing "less 
> >    than best effort" flows from "interactive" flows, and
> >    using that information to target efforts at bandwidth
> >    upgrades. LBE flows don't call for bandwidth 
> >    upgrades; interactive flows do.
> 
> I don't see how this can be done by CONEX, traffic class 
> (priority) is not conveyed by CONEX. 

If an ingress router (BRAS) checks the average ConEx Predicted
Congestion marking of a single flow, and compares that against the
average marking rate of that user/port, wouldn't that implicitly convey
information about the traffic class a end user wishes its traffic to be
in?

Ie. LBE would probably have lower-than-average Conex markings, while
interactive flows a higher marking. If the end user wouldn't want that
traffic to cause congestion somewhere in the network, s/he wouldn't mark
them at a higher-than-average rate, but instead throttle the bandwidth
until the marking would be close to average...

Or is that just wishful thinking :)

Richard Scheffenegger

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Sep 2010 05:49:00 -0400

> information about the traffic class a end user wishes its traffic to be

   Yes.

> interactive flows a higher marking.

   Clearly, a LBE flow will simply not send when expected congestion
exceeds some percentage.

   I would expect a LBE flow to also estimate low when starting a flow
(before actual congestion feedback has been received), but we shouldn't
depend on that.

> If the end user wouldn't want that traffic to cause congestion somewhere
> in the network, s/he wouldn't mark them at a higher-than-average rate,
> but instead throttle the bandwidth until the marking would be close to
> average...

   "Higher-than-average rate" may not be quite the right algorithm,
since it's really hard to compute a meaningful "average". I would expect
LBE traffic to set an upper bound of what fraction of congestion it's
willing to estimate on traffic it sends -- absolute, not as-compared-to-
average.

   So your ingress router would probably see a lower marking rate for
LBE traffic, but the real sign is that such traffic disappears when
the marking rate gets high enough.

   The point, after all, is to have a reliable signal of when upgrading
bandwidth is called for.

--
John Leslie <[email-masked]>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 15 Sep 2010 12:48:55 +0100

Hi John,

The issue I see with some absolute limits is that you can not really
know what absolute level that might be. After all, tuning RED parameters
is still a black art, and even if you can not (as admin) tune RED, each
vendor likely has different implementations which align best with the
specific hardware...

I do understand that standard ECN TCP will react to any number of CE
marks per cwnd as non-ECN TCP would. However, prescribing a fixed, say,
2% maximum marking rate, would again make further evolution of (ECN) TCP
(and other protocols, near impossible.

Just as an example, from my understanding, DCTCP may require much higher
marking rates (up to 100%) for some RTTs to run properly. One can now
argue, that such enhancements might only work in enclosed environments,
but again I think that's against the spirt of TCP....

In summary, I'm against fixed absolute values to denote LBE or other
implicit service levels... Unless, there is a ridig set of RED
parameters which have to go with it too...(? Need to think about that,
though)

Richard

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]] 
>
> > If the end user wouldn't want that traffic to cause congestion 
> > somewhere in the network, s/he wouldn't mark them at a 
> > higher-than-average rate, but instead throttle the 
> bandwidth until the 
> > marking would be close to average...
> 
>    "Higher-than-average rate" may not be quite the right 
> algorithm, since it's really hard to compute a meaningful 
> "average". I would expect LBE traffic to set an upper bound 
> of what fraction of congestion it's willing to estimate on 
> traffic it sends -- absolute, not as-compared-to- average.
> 
>    So your ingress router would probably see a lower marking 
> rate for LBE traffic, but the real sign is that such traffic 
> disappears when the marking rate gets high enough.
> 
>    The point, after all, is to have a reliable signal of when 
> upgrading bandwidth is called for.
> 
> --

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Sep 2010 09:31:50 -0400

> traffic to cause congestion somewhere in the network, s/he wouldn't mark

it's highly unlikely that the end-user understands 'cause congestion
somewhere in the network', it's also highly unlikely that 'somewhere
in the network' is a helpful measure for the end user.

I think you mean: "cause their internet experience (for this
application, ie: yahoomail/gmail/vonage/quake) to degrade at this
time"

-chris

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Sep 2010 10:21:11 -0400

Scheffenegger, Richard <[email-masked]> wrote:
> know what absolute level that might be.

   This is quite true, actually...

   (We know what level of packet-drop will seriously impede TCP-reno
traffic of a particular rate for a particular RTT; but we know neither
the desired flow nor the RTT for all competing traffic, for example.)

   Nonetheless, I expect LBE algorithms to converge towards a fairly
conservative "congestion probability", and I expect that to be stated
as an absolute packet-drop probability, not as a relative percentage
of "average" packet-drop probability (whatever that means).

> After all, tuning RED parameters is still a black art, and even if
> you can not (as admin) tune RED, each vendor likely has different
> implementations which align best with the specific hardware...

   I believe we're distancing ConEx from ECN, though it's still early
to say whether the ConEx mechanism might build on ECN. (I've been
toying with a possible ConEx mechanism quite separate from ECN...)

   If we do adopt a ConEx mechanism which depends on ECN, I agree we
won't be able to depend upon many details of the RED algorithm driving
the ECN marks.

   But I believe regardless of the model, along a path _I_ consider
"completely uncongested" there should be no "congestion experienced"
marked; so a lower-bound of 0% is quite possible.

   If LBE protocols were to base their trigger on "average congestion
probability", I still wouldn't expect them to use an instantaneous
"average." An "off-hours average" would be more reasonable; but that
would have to come from some database...

> marks per cwnd as non-ECN TCP would. However, prescribing a fixed,
> say, 2% maximum marking rate, would again make further evolution of
> (ECN) TCP (and other protocols), near impossible.

   I would be _very_ disturbed if any LBE algorithm intentionally allowed
2% packet drop to be "normal"!

> Just as an example, from my understanding, DCTCP may require much
> higher marking rates (up to 100%) for some RTTs to run properly.

   Now we're on a different topic...

   ECN marking, in fact, is often too coarse, in addition to being too
loosely defined. I'm quite agreeable to designing the ConEx mechanism
to have marking which is less coarse -- in other words, marking which
signals packet-drop-probability much less than 100%. (Indeed, I see
benefit in being able to signal packet-drop probability of less than
0.01%.) IMHO, ECN isn't the right tool for that, but I can easily
envision a ConEx mechanism which would signal such low percentages.

> One can now argue, that such enhancements might only work in enclosed
> environments,

   I wouldn't agree with that.

> but again I think that's against the spirit of TCP....

   Hmm... are we going to get into a flamewar _here_ about what the
"Internet Founders Actually Anticipated"... ;^)

> implicit service levels...

   I don't believe it is in-charter to prescribe any such thing.

> Unless, there is a rigid set of RED parameters which have to go
> with it too...(? Need to think about that, though)

   I'm quite sure rigid RED parameters are out-of-scope for ConEx.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 16 Sep 2010 18:13:41 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christopher Morrow
> Sent: 15 September 2010 14:32
> To: Scheffenegger, Richard
> Cc: Kevin Mason; [email-masked]
> Subject: Re: [conex] comments on draft-moncaster-conex-concepts-uses-
> 01.txt
> 

Indeed (unless the user is an IETF geek...)

> application, ie: yahoomail/gmail/vonage/quake) to degrade at this

Yep...

And that is why we would hope that application developers would provide
users with "meaningful" interfaces to do this for them.

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