Subject: [Banana] FW: New Version Notification for draft-leymann-banana-ecn-00.txt

From: chenlihao <[email-masked]>
Date: Tue, 12 Sep 2017 08:03:32 +0000

Hi all,

The BANANA-ECN issue was discussed during the BANANA side meeting in Prague. We think that the idea of ECN operations for bonding tunnels make sense. Therefore, we post the draft "BANdwidth Aggregation for interNet Access (BANANA) ECN Operations for Bonding Tunnels".

Please find the links of the draft below. Comments are welcomed!

Best regards,
Lihao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 12, 2017 2:49 PM
To: Gengxuesong (Geng Xuesong); chenlihao; Zhangmingui (Martin); 4c 67; Cornelius Heidemann; Liang Geng; Jun Shen; Nicolai Leymann
Subject: New Version Notification for draft-leymann-banana-ecn-00.txt

A new version of I-D, draft-leymann-banana-ecn-00.txt has been successfully submitted by Lihao Chen and posted to the IETF repository.

Name:		draft-leymann-banana-ecn
Revision:	00
Title:		BANdwidth Aggregation for interNet Access (BANANA) ECN Operations for Bonding Tunnels
Document date:	2017-09-12
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-leymann-banana-ecn-00.txt
Status:         https://datatracker.ietf.org/doc/draft-leymann-banana-ecn/
Htmlized:       https://tools.ietf.org/html/draft-leymann-banana-ecn-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-leymann-banana-ecn-00

Abstract:
   This document specifies a Bonding Tunnel ECN Mechanism that uses
   Explicit Congestion Notification (ECN) in bonding tunnels to notify
   congestion of a tunnel so that the load-balancing strategy of the
   tunnel ingress can be adjusted accordingly. Attributes for the
   control protocol of BANANA are defined to support this mechanism.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Menth <[email-masked]>
Date: Wed, 13 Sep 2017 10:30:57 +0200

Dear Lihao and coauthors,

thanks for your contribution. I have some comments.

1) The relation of your document to
https://www.ietf.org/id/draft-ietf-tsvwg-tunnel-congestion-feedback-05.txt
may be clarified. That draft sends aggregated ECN feedback from a
receiver to a controller using IPFIX while your proposal sends
per-packet feedback on the tunnel to the tunnel ingress (which may be a
controller).

2) It may be helpful to extend the feedback information by packet loss.
A generalization of your approach seems helpful.

3) As 1) shows, feedback may be sent either in regular intervals or
per-packet. That pertains for both congestion signals: loss and delay.
Those are design options for general congestion feedback in BANANA.

4) When using ECN information from the tunnel, there may be a double
reaction to congestion: on the one hand traffic is shifted to another
tunnel, on the other hand end-to-end flows reduce their rate. I don't
say this is a problem, but we should be aware of it.

Kind regards,

Michael

Am 12.09.2017 um 10:03 schrieb chenlihao:
> _______________________________________________
> Banana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/banana
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: chenlihao <[email-masked]>
Date: Wed, 13 Sep 2017 09:52:31 +0000

Hi Michael

Thanks for your comments. Please see in line.

Lihao

> From: Michael Menth [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2017 4:31 PM
> To: chenlihao; [email-masked]
> Cc: Andreas Stockmayer; Tobias Scherer
> Subject: Re: [Banana] FW: New Version Notification for
> draft-leymann-banana-ecn-00.txt
> 
> may be clarified. That draft sends aggregated ECN feedback from a receiver to
> a controller using IPFIX while your proposal sends per-packet feedback on the
> tunnel to the tunnel ingress (which may be a controller).
>
Thanks for the information.

> 3) As 1) shows, feedback may be sent either in regular intervals or per-packet.
> That pertains for both congestion signals: loss and delay.
For 2) and 3), I agree that those are design options for general congestion feedback in BANANA and would be well defined in the future. Therefore, ECN notification could be supported by the general congestion feedback method of BANANA.

> reaction to congestion: on the one hand traffic is shifted to another tunnel, on
> the other hand end-to-end flows reduce their rate. I don't say this is a problem,
> but we should be aware of it.
> 
Yes, we should be aware of it. And I think for BANANA scenarios, if the problem of congestion could be handled by shifting traffic to another tunnel, we might not need to reduce end-to-end flow rate.

> > The BANANA-ECN issue was discussed during the BANANA side meeting in
> Prague. We think that the idea of ECN operations for bonding tunnels make
> sense. Therefore, we post the draft "BANdwidth Aggregation for interNet
> Access (BANANA) ECN Operations for Bonding Tunnels".
> >
> > To: Gengxuesong (Geng Xuesong); chenlihao; Zhangmingui (Martin); 4c
> > 67; Cornelius Heidemann; Liang Geng; Jun Shen; Nicolai Leymann
> > A new version of I-D, draft-leymann-banana-ecn-00.txt has been successfully
> submitted by Lihao Chen and posted to the IETF repository.
> >
> > URL:
> https://www.ietf.org/internet-drafts/draft-leymann-banana-ecn-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-leymann-banana-ecn/
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-leymann-banana-ecn-00
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: <[email-masked]>
Date: Wed, 20 Sep 2017 08:38:55 +0000

Thanks for the document.  Support of ECN seems important to me.

<< At the tunnel egress, if the outer IP headers from Tunnel 1 and
   Tunnel 2 are both CE and the inner IP headers are ECT, the ECN field
   of the outgoing packet will be set to CE.>>
I don't understand, isn't the decision being made packet by packet?

<< The local BANANA box (could be either the tunnel ingress or the
   tunnel egress) uses the ECN Capability to notify the remote BANANA
   box (could be either the tunnel egress or the tunnel ingress) that
   the local BANANA box supports the Bonding Tunnel ECN Mechanism. The
   first GRE Tunnel Setup Request message [RFC8157] MAY include the ECN
   Capability attribute.>>
I think this is something actually in scope of the Banana control protocol, whereas (if I get it right) your solution assumes that (& only works if) GRE is being used for the "banana encapsulation".

Best wishes,
phil

-----Original Message-----
From: Banana [mailto:[email-masked]] On Behalf Of chenlihao
Sent: 12 September 2017 09:04
To: [email-masked]
Subject: [Banana] FW: New Version Notification for draft-leymann-banana-ecn-00.txt

Hi all,

Best regards,
Lihao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 12, 2017 2:49 PM
To: Gengxuesong (Geng Xuesong); chenlihao; Zhangmingui (Martin); 4c 67; Cornelius Heidemann; Liang Geng; Jun Shen; Nicolai Leymann
Subject: New Version Notification for draft-leymann-banana-ecn-00.txt

Abstract:

The IETF Secretariat

---

From: chenlihao <[email-masked]>
Date: Thu, 21 Sep 2017 02:50:05 +0000

Hi Philip,

Thanks for your comments. Please see inline.

Best wishes,
Lihao

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 20, 2017 4:39 PM
> Subject: RE: New Version Notification for draft-leymann-banana-ecn-00.txt
> 
>    of the outgoing packet will be set to CE.>> I don't understand, isn't the
> decision being made packet by packet?

I'd like to update this part in future versions to make the description more accurate. Maybe like this: "At the tunnel egress, the ECN field of the outgoing packet will not be set to CE unless both conditions are met: 1. This packet's outer IP header is CE; 2. Before a specific time period, there has been at least one packet from the other tunnel with a CE outer IP header."  The intuition here is, we don't have to reduce the end-to-end sending rate unless both tunnels are suffered from congestion.

> I think this is something actually in scope of the Banana control protocol,
> whereas (if I get it right) your solution assumes that (& only works if) GRE is
> being used for the "banana encapsulation".

I'm relatively familiar with GRE, so I just use it as an example for realizing the ECN idea. I think it can be applied to other banana encapsulations as well.

> To: Gengxuesong (Geng Xuesong); chenlihao; Zhangmingui (Martin); 4c 67;
> Cornelius Heidemann; Liang Geng; Jun Shen; Nicolai Leymann