Re: [re-ECN] TCP's "Dynamic Range"

[John Leslie <[e-mail]>]

Bob Briscoe wrote:
> At 13:36 26/10/2009, John Leslie wrote:
>
>> (BTW, that's an issue we need to be prepared to discuss: how can
>> re-ecn operate when ECN marks are suppressed? Even though most of
>> the suppression history concerns ICMP, there will be folks who think
>> ECN will suffer similar suppression.)
>
> As this sentence is in the passive, I assume you mean suppression by the 
> transport or some other link than the congested one (not suppression by 
> the congested link itself).

   Mostly I was thinking "firewalls", but yes, my intent was suppression
anywhere on the path, not suppression due to a packet being dropped.

> That's why we brought re-ECN to the IETF - because we had solved that 
> problem. The draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt explains 
> the mechanisms that can be built over re-ECN to detect & prevent 
> suppression.

   I'm confident Bob _can_ address this issue...


>> I believe that a properly-designed signalling system can work
>> for at least eight or nine orders of magnitude of sender bandwidth.
>> To be complete, a proposal should probably get into how many bits
>> per signal, but I'm personally convinced that re-ecn can work
>> beyond five orders of magnitude.
>
> Have you been following Matt Mathis's work on Relentless TCP?

   Somewhat... not in every detail.

> And generally on TCP algos with window proportional to 1/p, rather
> than 1/sqrt(p) like current TCP. The idea is these maintain the same
> number of loss or ECN signals per window however fast you go.

   Very promising work, though it's not entirely clear how to get it
deployed... I guess I was hoping deployment will be easier with ConEx
in place.

> Is there some reason for choosing 8 or 9 orders of magnitude? I would 
> have thought 1/p would scale indefinitely, but you may be thinking of 
> other factors I've missed.

   Just an idiosyncracy: I consider anything beyond 10 orders of
magnitude to be a different animal... and I didn't want to commit to
the 10th. ;^)

> Scaling was also one of the main motivations for Kelly's primal algo. 
> And it was one of my motivations for introducing re-ECN so we could 
> shift from the TCP-friendly (1/sqrt(p)) track painlessly onto a scalable 
> 1/p track without worrying about flow fairness.

   A worthy goal!

--
John Leslie <[e-mail]>