Subject: Re: [Lsr] Congestion (flow) control thoughts.

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 6 May 2020 07:11:12 +0000

Hi Tony,

Thank you for your explanation. Please find my comments inline.

Best Regards
Xuesong

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, May 1, 2020 12:16 AM
> To: Gengxuesong (Geng Xuesong) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] Congestion (flow) control thoughts.
>  
> 
> I consider flow control and congestion control to be separate, but similar
> problems.
> 
> Flow control is about creating a single control loop between a single
> transmitter and single receiver.
> 
> Congestion control is about creating multiple interacting control loops between
> multiple transmitters and multiple receivers.

<Xuesong> I think there is no need to distinguish the concept of flow control and congestion control, considering that the core idea is the same: monitor the sending rate to match the capability of the bottleneck, no matter there are competitors or not. And the control loop is necessary in both case. 

> In our draft, we are proposing other feedback mechanisms.

<Xuesong> Thank you for explaining about the bottleneck of flooding and different cc solutions that are under discussion. It is helpful and I will read the drafts. 
There is still one more question left in the previous email: " What is the criteria of comparing different solutions?". I think this is crucial for further discussion and comparative tests. I notice that in Bruno's data, some parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP delay", "retransmission time". I'm wondering whether it is able to choose a better solution through these parameters. If not, what should be added or considered. (Some other issues are also considered when choosing cc mechanism in layer 4, such as: fairness among flows, co-existence with other cc mechanism .. )

> Tony

---

From: [email-masked]
Date: Wed, 6 May 2020 09:02:02 -0700

Hi Xuesong,

> <Xuesong> I think there is no need to distinguish the concept of flow control and congestion control, considering that the core idea is the same: monitor the sending rate to match the capability of…

This matches my perspective.

> There is still one more question left in the previous email: " What is the criteria of comparing different solutions?". I think this is crucial for further discussion and comparative tests. I notic…

Sorry for missing the question. The criteria are, I think, quite clear: minimize overall flooding time.  As Bruno’s figures show, that does NOT happen simply by transmitting at the maximum rate. That causes overruns, resulting in retransmissions and that ends up being quite slow (tho we can work on that too). The question then is: what control mechanisms do we put in place to ensure minimal flooding time? This needs to interoperate across the full spectrum of implementations: fast brand X needs to not overrun slow brand Y while performing well with fast brand Z.

The floor is very much open.

Tony

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 7 May 2020 10:28:41 +0000

Hi Tony,

I agree that "minimal flooding time " is a good choice, which may differ from the traditional cc in layer 4, which is difficult to get the completion time for each flow.
I am still a little confused about " fast brand X needs to not overrun slow brand Y while performing well with fast brand Z". Is this talking about interoperation between different company device, which may use different type of cc mechanism?

Best Regards
Xuesong 

> From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, May 7, 2020 12:02 AM
> Cc: [email-masked]; Christian Hopps <[email-masked]>
> > <Xuesong> I think there is no need to distinguish the concept of flow control
> and congestion control, considering that the core idea is the same: monitor the
> sending rate to match the capability of the bottleneck, no matter there are
> competitors or not. And the control loop is necessary in both case.
> 
> 
> > <Xuesong> Thank you for explaining about the bottleneck of flooding and
> different cc solutions that are under discussion. It is helpful and I will read the
> drafts.
> > There is still one more question left in the previous email: " What is the
> criteria of comparing different solutions?". I think this is crucial for further
> discussion and comparative tests. I notice that in Bruno's data, some
> parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP
> delay", "retransmission time". I'm wondering whether it is able to choose a
> better solution through these parameters. If not, what should be added or
> considered. (Some other issues are also considered when choosing cc
> mechanism in layer 4, such as: fairness among flows, co-existence with other
> cc mechanism .. )
> 
> 
> Sorry for missing the question. The criteria are, I think, quite clear: minimize
> overall flooding time.  As Bruno’s figures show, that does NOT happen simply
> by transmitting at the maximum rate. That causes overruns, resulting in
> retransmissions and that ends up being quite slow (tho we can work on that
> too). The question then is: what control mechanisms do we put in place to
> ensure minimal flooding time? This needs to interoperate across the full
> spectrum of implementations: fast brand X needs to not overrun slow brand Y
> while performing well with fast brand Z.
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: [email-masked]
Date: Thu, 7 May 2020 08:28:08 -0700

Hi Xuesong,

> I am still a little confused about " fast brand X needs to not overrun slow brand Y while performing well with fast brand Z". Is this talking about interoperation between different company device,…

Yes, I’m talking about interoperability. 

Normally, in this working group, interoperability implies that each implementation is sending and receiving correctly formatted packets and computing correctly. This particular item adds in one other degree of complexity: timeliness. An implementation must be able to go fast or slow, depending on the needs of the receiver.

Tony

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 8 May 2020 08:31:35 +0000

Clear, thanks!

> Sent: Thursday, May 7, 2020 11:28 PM
> > I agree that "minimal flooding time " is a good choice, which may differ from
> the traditional cc in layer 4, which is difficult to get the completion time for
> each flow.
> > I am still a little confused about " fast brand X needs to not overrun slow
> brand Y while performing well with fast brand Z". Is this talking about
> interoperation between different company device, which may use different
> type of cc mechanism?
> 
> 
> Normally, in this working group, interoperability implies that each
> implementation is sending and receiving correctly formatted packets and
> computing correctly. This particular item adds in one other degree of
> complexity: timeliness. An implementation must be able to go fast or slow,
> depending on the needs of the receiver.
> 
> Tony