Subject: Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt

From: Matthieu Coudron <[email-masked]>
Date: Mon, 11 Aug 2014 17:50:17 +0200

Dear all,

we reviewed the draft and following offline discussions with Albert, you 
will find below a few comments.

Best regards,
Matthieu Coudron
Stefano Secci

____________________________
2. Underlay definition
"The underlay corresponds to the RLOC space"
This appears as too restrictive, as information about the underlay could 
come also from local AS/domain-level information such as traffic 
engineering databases, monitoring tools, etc, unaware of LISP.

____________________________
3.2 MPTCP
"Each of these sub-flows behaves as a legacy TCP flow and hence, from 
the network point of view, each sub-flow is a different TCP session. The 
network conditions over the different paths the sub-flows follow affect 
the whole MPTCP session.  Since MPTCP has to keep the aggregate session 
consistent, each aggregated flow can perform as good as the worst of the 
sub flows it integrates."

This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that 
MPTCP should be at least as good as TCP, which in practice is true 
except in a few cases (e.g., if a subflow with a large share of the 
window becomes inactive, then you need to wait several timeouts before 
being able to be aggressive enough on other subflows). The RFC does not 
precisely address the scheduling mechanisms, but if for instance you 
consider the Linux implementation (http://www.multipath-tcp.org), it 
sends a maximum amount of data on the subflow with the lowest RTT and 
once its window is full, it will send on the 2nd lowest RTT subflow 
etc... so providing there is enough buffering at each endpoint, in terms 
of sheer throughput MPTCP should be able to aggregate all the subflows 
independently of their latency. It is true though that if packets are 
not scheduled carefully on each subflow, then application latency may  
increase.

At LIP6, we already run LISP+MPTCP coupling experimentations (LISP 
providing topology informations and forwarding capabilities to the MPTCP 
layer), we documented last year in this article “Cross-layer Cooperation 
to Boost Multipath TCP Performance in Cloud Networks” available at: 
http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In 
our experiment, RTTs of the different paths were close to each other, 
which lead to very good performance, as the lower the RTT gap the better 
MPTCP performance.  See here another interesting article about this 
matter: "How hard can it be? Designing and Implementing a Deployable 
MPTCP" available at 
https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

____________________________
4. Requirements / Device Discovery
"This is solved for xTRs by sending Map Register messages."

Did you mean Map Requests? Or can you explain why only Map Register?

____________________________
4. Requirements / Forwarding Actions

"These actions can be implemented as extensions to the current 
specifications of LISP-TE or LISP-SR or be defined by means of a new LCAF."

Here it would be better not to exclude existing LCAF. For the MPTCP 
use-case, we have a prototype using already proposed LCAF messages.

____________________________
7. Security Considerations
"When including capabilities to allow for the discovery of devices and 
its capabilities, as well as the collection of metrics regarding the 
underlay and the local device itself, it should be taken into 
consideration that proper controls are put in  place to enforce strict 
policies as to which devices can access what type(s) of information."

Do you have any protocol in mind to get metrics from the overlay to the 
underlay?
Relevant nodes should be chosen carefully so that they are not malicious 
or misfunctioning. For instance the TCP RTT seen by a VM is higher than 
one seen by a physical machine due to the hypervisor scheduling latency.

On 11/08/2014 16:46, Matthieu Coudron wrote:
> ---------- Forwarded message ----------
> From: Alberto Rodriguez-Natal <[email-masked]>
> Date: 2014-07-04 15:16 GMT+02:00
> Subject: [lisp] Fwd: New Version Notification for
> draft-rodrigueznatal-lisp-oam-00.txt
> To: "[email-masked] list" <[email-masked]>
>
>
> Dear all,
>
> We have just submitted a new draft discussing OAM (Operations
> Administration Management) use-cases and requirements for LISP.
>
> Please, feel free to review it and provide feedback.
>
> Thanks,
> Alberto
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: Fri, Jul 4, 2014 at 10:01 PM
> Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt
> To: Albert Cabellos-Aparicio <[email-masked]>, Marc
> Portoles-Comeras <[email-masked]>, Alberto Rodriguez-Natal
> <[email-masked]>, Michael Kowal <[email-masked]>, Darrel Lewis
> <[email-masked]>, Fabio Maino <[email-masked]>
>
>
>
> A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt
> has been successfully submitted by Alberto Rodriguez-Natal and posted to the
> IETF repository.
>
> Name:           draft-rodrigueznatal-lisp-oam
> Revision:       00
> Title:          LISP-OAM (Operations Administration Management): Use
> cases and requirements
> Document date:  2014-07-04
> Group:          Individual Submission
> Pages:          13
> URL:
> http://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-oam/
> Htmlized:       http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00
>
>
> Abstract:
>     This document describes Operations Administration and Management
>     (OAM) use-cases and the requirements that they have towards the LISP
>     architecture.
>
>
>
>
> 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
>
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 18 Aug 2014 11:34:34 +0200

Hi Matthieu and Stefano,

Thank you very much for reviewing the draft. Your comments are deeply
appreciated.

Please see inline.

On Mon, Aug 11, 2014 at 5:50 PM, Matthieu Coudron <[email-masked]>
wrote:

> [AR] I think we could reword that. How about this text?

"In most cases the underlay is equivalent to the RLOC space, however it can
also comprise information from external sources such traffic engineering
databases, monitoring tools, etc"

> "Each of these sub-flows behaves as a legacy TCP flow and hence, from the
> network point of view, each sub-flow is a different TCP session. The
> network conditions over the different paths the sub-flows follow affect the
> whole MPTCP session.  Since MPTCP has to keep the aggregate session
> MPTCP should be at least as good as TCP, which in practice is true except
> in a few cases (e.g., if a subflow with a large share of the window becomes
> inactive, then you need to wait several timeouts before being able to be
> aggressive enough on other subflows). The RFC does not precisely address
> the scheduling mechanisms, but if for instance you consider the Linux
> implementation (http://www.multipath-tcp.org), it sends a maximum amount
> of data on the subflow with the lowest RTT and once its window is full, it
> will send on the 2nd lowest RTT subflow etc... so providing there is enough
> buffering at each endpoint, in terms of sheer throughput MPTCP should be
> able to aggregate all the subflows independently of their latency. It is
> true though that if packets are not scheduled carefully on each subflow,
> then application latency may  increase.
>
>
[AR] I believe that we are on the same page here. The point that we tried
to make here is that "on worst case scenario, MPTCP performs as good as
TCP". Perhaps that was not stated clearly enough. Maybe we could keep this
paragraph short (one sentence) and just point people to MPTCP RFC. Would
that make sense?

> layer), we documented last year in this article “Cross-layer Cooperation to
> Boost Multipath TCP Performance in Cloud Networks” available at:
> http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In our
> experiment, RTTs of the different paths were close to each other, which
> lead to very good performance, as the lower the RTT gap the better MPTCP
> performance.  See here another interesting article about this matter: "How
> hard can it be? Designing and Implementing a Deployable MPTCP" available at

[AR] Thank you very much for the pointers, they provide good insight for
this draft. They are greatly appreciated :)

> [AR] We were talking here about the fact that in vanilla LISP the
MappingSystem can be aware of existing xTRs since they keep sending
MapRegisters. The MapRegister process works already as an automated
discovery mechanism. We'll extend the sentence to clarify this.

[AR] Good point. How about this?

"These actions can be implemented as extensions to the current
specifications of LISP-TE or LISP-SR, leverage on reusing existing LCAF
types or be defined by means of a new LCAF."

> "When including capabilities to allow for the discovery of devices and its
> capabilities, as well as the collection of metrics regarding the underlay
> and the local device itself, it should be taken into consideration that
> proper controls are put in  place to enforce strict policies as to which
> devices can access what type(s) of information."
>

[AR] We're currently discussing this. Nothing fixed yet ;)

> or misfunctioning. For instance the TCP RTT seen by a VM is higher than one
> seen by a physical machine due to the hypervisor scheduling latency.

[AR] That's indeed correct. We'll try to keep that in mind.

Thanks again for your comments. We hope you can keep contributing to this
draft :)

Best,
Alberto

---

From: Matthieu Coudron <[email-masked]>
Date: Tue, 26 Aug 2014 13:04:52 +0200

We agree with your corrections. See comments inline.

Cheers

Matthieu Coudron
Stefano Secci

 >     This appears as too restrictive, as information about the underlay
 >     could come also from local AS/domain-level information such as
 >     traffic engineering databases, monitoring tools, etc, unaware of 
LISP.
 > "In most cases the underlay is equivalent to the RLOC space, however it
 > can also comprise information from external sources such traffic
 > engineering databases, monitoring tools, etc"
ok

 >     "Each of these sub-flows behaves as a legacy TCP flow and hence,
 >     from the network point of view, each sub-flow is a different TCP
 >     session. The network conditions over the different paths the
 >     sub-flows follow affect the whole MPTCP session.  Since MPTCP has to
 >     keep the aggregate session consistent, each aggregated flow can
 >     perform as good as the worst of the sub flows it integrates."
 >
 >     This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states
 >     that MPTCP should be at least as good as TCP, which in practice is
 >     true except in a few cases (e.g., if a subflow with a large share of
 >     the window becomes inactive, then you need to wait several timeouts
 >     before being able to be aggressive enough on other subflows). The
 >     RFC does not precisely address the scheduling mechanisms, but if for
 >     instance you consider the Linux implementation
 >     (http://www.multipath-tcp.org)__, it sends a maximum amount of data
 >     on the subflow with the lowest RTT and once its window is full, it
 >     will send on the 2nd lowest RTT subflow etc... so providing there is
 >     enough buffering at each endpoint, in terms of sheer throughput
 >     MPTCP should be able to aggregate all the subflows independently of
 >     their latency. It is true though that if packets are not scheduled
 >     carefully on each subflow, then application latency may  increase.
 >
 >
 > [AR] I believe that we are on the same page here. The point that we
 > tried to make here is that "on worst case scenario, MPTCP performs as
 > good as TCP". Perhaps that was not stated clearly enough. Maybe we could
 > keep this paragraph short (one sentence) and just point people to MPTCP
 > RFC. Would that make sense?
Agreed with both points. The document should focus on how MPTCP can 
benefit from LISP and there are several ways. The one you present is to 
focus on maximally disjoint paths to support the best link backup 
scenario. If increased throughput is the goal of the scenario, then 
maximally disjoint paths may not be the best solution; the subflows 
could share some links as long as this link is not a bottleneck for the 
connection.
An additional scenario could be to forward at least one subflow on a 
LISP path that is considered secure, e.g., over it it would be harder 
for an attacker to rebuild the stream of data.

 > discovery mechanism. We'll extend the sentence to clarify this.

ok - it seems more appropriate to replace "xTRs" with "ETRs".

ok