Re: [iccrg] introducing draft-even-iccrg-dc-fast-congestion

["Huangyihong (Rachel)" <[e-mail]>]

Hi Jake and Michael,

Thanks for the feedback.

It's not our intention to publish this specific draft as an RFC. What we want is to stimulate some discussions on what the standard community can do with such a direction. We've already know a lot of attempts in academic area, How it can convert to something that can be widely supported in the industry is what we are chasing.

BTW, this will be presented in the side meeting on Tuesday morning as announced by Paul, where we're going to show some initial test results for discussion.

BR,
Rachel

-----邮件原件-----
发件人: iccrg [mailto:[e-mail]] 代表 Holland, Jake
发送时间: 2019年11月13日 17:58
收件人: Michael Welzl <[e-mail]>; iccrg IRTF list <[e-mail]>
主题: Re: [iccrg] introducing draft-even-iccrg-dc-fast-congestion

+1, I agree with most of what Michael said.  What the doc is suggesting
sounds like a useful direction to me.

I'm not sure the doc itself is useful to publish as an RFC, I'd be more interested in a proposal that tries to do what the doc describes.  But I do think the ideas put forth are interesting and would encourage efforts to make them reality.

Intuitively, I'd think that with direct communication with network nodes in a controlled environment, it should be possible to get better performance more robustly than what you can do with inferring status a bit at a time from reflecting CE/SCE marks in acks, and it would be very cool to see an attempt to make that work well.

Best,
Jake

On 2019-11-03, 23:59, "Michael Welzl" <[e-mail]> wrote:

Hi,


> On 29 Oct 2019, at 07:34, Roni Even (A) <[e-mail]> wrote:
> 
> Hi,
> We submitted the draft after discussing the topic of better congestion control for Data Centers in the last IETF meeting.
> The objective was to look at current congestion control mechanisms and propose a possible direction for DC CC.
>  
> The direction that looks promising to us is to reflect the network status more accurately taking into account that we are talking about a single DC domain.
>  
> We are looking for feedback if this direction looks promising and if there is an interest in working on this direction.

In my opinion, regarding "does this direction look promising": absolutely yes!   Internet congestion controls work with a secondary and very limited signal (implicit feedback, as the result of queuing behavior); if you have the luxury of using an earlier signal (as in mechanisms like HPCC), that should be strictly superior. E.g. DCTCP is a lot better than normal TCP, but still, the increase behavior is the same, as it's just clueless until the queue grows at least a little bit.


> The draft have some open questions that need to be addressed.

Some of them are very much case-by-case. E.g.: "Hardware implications" depend on the hardware  :)   And: "How to authenticate the validity of the data." - why do you need to, in your own datacenter?

These two issues are from a section that deals with giving feedback to the sender faster, e.g. by piggybacking on reverse traffic. My suggestion would be to consider this a second step, and deal with first things first - the questions in the section on "Reflect the network status more accurately". There, it very much depends on the mechanism that you want to use. E.g., the answer to: "How to add the metadata to the forward stream" may depend on the mechanism, as the amount of data to convey may differ quite a bit from one case to another. Your related text in section 4.4 seems to be quite focused on HPCC - that's not the only possible explicit feedback based mechanism. E.g., once upon a time, people discussed XCP, RCP, MaxNet, and several more of that nature...  but maybe HPCC is indeed the one that is most realistic to deploy?  Though, that said, it would really be worth taking a longer look at related literature. E.g., HULL might be realistic to deploy in datacenters just as well: 
  https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf

So, I guess, the question here is: are you asking in general, or (perhaps reasonably so) about HPCC only?


>  Please review the draft and provide feedback.

This draft is a broad overview that asks broad questions - maybe too broad to reasonably discuss them, as almost every question here could be answered with "it depends".
Perhaps you should already make some design decisions of your own and narrow things down a bit.


> Thanks
> Roni Even


Cheers,
Michael

_______________________________________________
iccrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/iccrg

_______________________________________________
iccrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/iccrg